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(54) System for controlling the distribution and use of composite digital works 



(57) A system for controlling use and distribution of 
composite digital works. A digital work is comprised of 
a description part (700) and a content part. The descrip- 
tion part contains control information for the composite 
digital work. The content part stores the actual digital 
data comprising the composite digital work. The de- 
scription part (700) is logically organized in an acyclic 
structure, e.g. a tree structure. For a composite digital 
work each node of the acyclic structure represents an 
individual digital work or some distribution interest in the 
composite digital work. A node in the acyclic structure 
is comprised of an identifier (701 ) of the individual work, 



usage rights (704) lor the individual digital work and a 
pointer (705.706) to the digital work. Composite digital 
works are stored in repositories. A repository has two 
primary operating modes, a server mode and a request- 
er mode. When operating in a server mode, the repos- 
itory is responding to requests to access digital works. 
When operating in requester mode, the repository is re- 
questing access to a digital work. A repository will proc- 
ess each request to access a composite digital work by 
examining the usage rights for each individual digital 
work found in the description part of the composite dig- 
ital work. 
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Description 

The present invention relates to the field of distribution and usage rights enforcement lor d.Oi.allv encoded work, 
A fundamental .ssue facing the publishing and information industries as they consider electronic publ.sn.na i« hew 
to prevent the unauthorized and unaccounted distr.ou.ion or usage of electronically published materials Electron ca.lv 
published materials are typically distributed ,n a digital form and recreated on a computer based system having the 
capao.l.ty to recreate the materials. Audio and video recordings, software, books and multimedia works are all bemq 
electronically published. Companies in these industries receive royalties for each accounted for delivery c( the mate- 
rials, e.g. the sale of an audio CD a. a retail outlet. Any unaccounted distribution of a work results ,n an unpaid royalty 
(e.g. copying the audio recording CD to anotner digital medium ) 

Th. I h /n! aSe ' n e ' e f ronica "y Pushed works can be "perfectly" reproduced and distnbuted is a major concern 
I I T 9 J W ° rkS ° V6r ne,WOfkS iS comm °nP'ace. One such widely used network is the Interne. The 
enZl llZ T Z?T k ,3Ci,i,y bV WhlCh C ° mpU,er USSrS in manv diversities, coroora.ions and oovernmen. 
TeZZsTZTlT* B ho S T in, ° rmali0n C ° mpU,er bU " e,,n b ° ardS fOUnd ° n the lnIe ™< and^commerca. 
IJ^D^^TSmI'i? f a J'° W POSt ' n9 re,neV,n9 ° f d, 9" ai -Nation. Information services 
such as Dialog and LEXIS/NEXIS prov.de databases of current information on a wide variety of topics Another factor 

;> r;«r:; s ,he deve,opment and expans,on ct ihe Na,i ° nai 

nlr , h k \ 9fOWS ,hS transmission <* works over networks w-ll increase many times 

20 copying * " ™ ^ ** °' d ' 9i,al W ° fk£ Wi,hOUl ,he ,ear of widespread unauthorized 

The most straightforward way to curb unaccounted dist, ibution is to prevent unauthor ized copying and transmis- 
s,on. For existing materials that are distributed in digital form vanous safeguards are used In the case of so. tvva e 

^ectdT ? emeS T* " mi! nUmb6r °' COP,SS ,ha ' bS made ° r Wh ' Ch —P" he output when coping 
of ZlZ , TT T " SCh6me CaUS8S SO, * Ware '° b6COme d ' Sabled a,,er a P-de.ermmed period 

be oTesen lonZ T WOrksta,,on bascd s °«warc - '° require .ha. a special hardware dcv.ee must 

f or r WOr t ksta,,on ln ° rder for ^"ware .o run. e.g.. see US-A-4.932.054 entitled 'Method and Apparatus 

for Protecting Computer Software Utilizing Coded Filter Network in Conjunction with an Active Coded Hardware Device 
Such devices are provided with the software and are commonly referred to as dongles 

H,=,r , t an0,h r SChem ! ^ ,0 diS,nbU,e S ° ,tWare bU ' Wh ' Ch requ,res a " kev " lo ena ble its use This is employed in 
distribution schemes where "demos" of the software are provided on a medium along wrth the entire product The 
demos can be Ueely used, but in order to use the actual product, the key mus. be purchased These schemes do not 
hinder copying of the software once the key is initially purchased 

ai^^ST"* ,nVent '° n * By " m 8nd me ' h ° d ^ ^ use a " d 

The invention accordingly provides a system and method as claimed in the accompanying claims 
A system for controlling use and distribution of composite digital works is disclosed A composite digital work is 

Z'^° !" e 0, h m ° re , indiVidUa ' d ' 9 " al W ° rkS An indiv,dual dl9,,al work IS a "V wriuen *>«*■ graphical or video 
m^^h u tranS ' ated t0 ° f Crea ' ed ' n 3 d ' 9iIal ,0rm and which can be recrea «ed using suitable rendering 
work tZ . II S ° 6 , Pr ° 9r r S A ,0 ' der C ° ntain,n9 ° ne ° r m ° re d ' 9 " al WOrks ma V be lreated as a composite dfcitel 
^! hln TT 7 T 3 ' OWS ° Wner °' an ind ' V,dual dlQ,tal work IO attach u ^ge rights to their work wSich 
Zu rt r h 1 the ' nd,v,dual d '9 i,al ^rk is incorporated into a composite digital work. The usage rightefoMhe 

Z vidu^ia^r,' 7 di9i,a ' W ° fk ^ be US9d 3nd diS,r ' bU,ed The a 99regat,on o, the usa'ge £ me 

L whot £ Tl T 3 C ° mPOSIte d ' 9i,al W ° rk 35 We " 35 USage r '9 h,s a,Iached to ,he composite digital work as 
a whole define how the composite digital work may be used and distributed 

for ttaS^'S £7""? deSCnpl,0n P art and a conlent Part- The description par, contains control information 
?he W ° rk | COn ' enl Pan SIOfeS ,he aCtUa ' di9 " al da,a com Pr'^hg the composite digital work 

lach n^e a Mhe' * h ^ aCyC " C S,rUCtUre (G ' 9 a Uee StrucIure > For a composite dfgi.al work 

7nZ^, Z , " 'presents an individual digital work o, some dist.ibu.ion inte.es. ,n the digit., work 

A node tn the acyclic st.uc.ure ,s comprised of an identifier of the individual wo.k. usage nghts fo, the .ndividual digital 
work and a pointer to the digital work. In this representation, .he description part may rJurafly be s tored sepLrmeTJ 
on a separate medium from the content part. separately 
Composite digital works are stored in repositories. A repository is comprised of a storage means for storing a dicital 
work and ,ts attached usage rights, an externa, interface for receiving and transmitting dal a processo^nd a 2S 

ss iT^r ha V W ° Prima,V ° Pera,,n9 m ° deS 3 SSrV6r m ° de and a reduesler ™ d * When'opera "gTn a i s^ er 
mode, the repository ,s responding to requests to access digital works. When operating ,n requester mode the repos 

bH^m-rt" 9 aCC6SS 10 ' dl9i,al W ° rk A reP ° Si,0ry Wi " Pr ° cess each reduesl '° access^ composT ^d g Z k 
by examining the usage rights for each individual digital work found in the description part Access is oraXd 7Z» 
composite digita. work i, access to each of the .ndividual digital works can be granted aZLu^ "cc^s to a,! the 
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individual digital works cannot be granted partial access can be granted only to those individual digital works whicn 
grant access 

A system and method in accordance with the invention will now be described, by way of example, with reference 
to the accompanying drawings, in which :- 
5 Figure 1 is a flowchart illustrating a simple instantiation of the operation of the currently preferred embodiment of 

the present invention. 

Figure 2 is a block diagram illustrating the various repository types and the repository transaction flow between 
them in the currently preferred embodiment of the present invention. 

Figure 3 is a block diagram of a repository coupled with a credit server in the currently preferred embodiment of 
10 the present invention. 

Figures 4a and 4b are examples of rendering systems as may be utilized in the currently preferred embodiment 
of the present invention. 

Figure 5 illustrates a contents file layout for a digital work as may be utilized in the currently preferred embodiment 
of the present invention. 

is Figure 6 illustrates a contents file layout for an individual digital work of the digital work of Figure 5 as may be 

utilized in the currently preferred embodiment of the present invention. 

Figure 7 illustrates the components of a description block ot the currently preferred embodiment ot the present 
invention. 

Figure S illustrates a description tree for the contents file layout of the digital work illustrated in Figure 5. 
20 Figure 9 illuslrates a portion ol a description tree corresponding to the individual digital work illustrated in Figure 6. 

Figure 10 illustrates a layout for the rights portion of a description block as may be utilized in the currently piefened 
embodiment of the present invention. 

Figure 11 is a description tree wherein certain d-blocks have PRINT usage rights and is used to illustrate "strict" 
and "lenient" rules for resolving usage rights conflicts. 
25 Figure 12 is a block diagram of the hardware components of a repository as arc utilized in the currently preferred 

embodiment of the present invention. 

Figure 13 is a block diagram of the functional (logical) components of a repository as are utilized in the currently 
preferred embodiment of the present invention. 

Figure 14 is diagram illustrating the basic components of a usage right in the currently preferred embodiment of 
30 the present invention 

Figure 15 lists the usage rights grammar of the currently preferred embodiment of the present invention. 

Figure 16 is a flowchart illustrating the steps of certificate delivery, hottist checking and performance testing as 
performed in a registration transaction as may be performed in the currently preferred embodiment of the present 
invention. 

35 Figure 17 is a flowchart illustrating the steps of session information exchange and clock synchronization as may 

be performed in the currently preferred embodiment of the present invention, after each repository in the registration 
transaction has successfully completed the steps described in Figure 16. 

Figure 18 is a flowchart illustrating the basic flow for a usage transaction, including the common opening and 
closing step, as may be performed in the currently preferred embodiment of the present invention. 

40 Figure 1 9 is a state diagram of server and client repositories in accordance with a transport protocol followed when 

moving a digital work from the server to the client repositories as may be performed in the currently preferred embod- 
iment of the present invention. 

OVERVIEW 

45 

A system for controlling use and distribution of digital works is disclosed. The present invention is directed to 
supporting commercial transactions involving digital works. 

Herein the terms "digital work", "work" and "content" refer to any work that has been reduced lo a digital repre- 
sentation. This would include any audio, video, text, or multimedia work and any accompanying inteipieter (e.g. soft- 
50 ware) that may be required for recreating the work. The term composite work refers to a digital work comprised ot a 
collection of other digital works. The term "usage rights" or "rights" is a term which refers to rights granted to a recipient 
of a digital work. Generally, these rights define how a digital work can be used and if it can be further distributed. Each 
usage right may have one or more specified conditions which must be satisfied before the right may be exercised. 

Figure 1 is a high level flowchart omitting various details but which demonstrates the basic operation of the present 
ss invention. Referring to Figure 1 , a creator creates a digital work step 1 01 . The creator will then determine appropriate 
usage rights and fees, attach them to the digital work, and store them in Repository 1 ; step 102. The determination of 
appropriate usage rights and fees will depend on various economic factors The digital work remains securely in Re- 
pository 1 until a request for access is received. The request for access begins with a session initiation by another 
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repository. Here a Repository 2 initiates a session wan Repository 1 step 103 As will oe descr.oed in areata detail 
below, this session initiation includes steps which helps to insure thai the respective repositories are I nisi worthy As- 
suming that a session can b- established. Repository 2 may then request access to the Diaital Work tor a stated 
purpose, step 104. The pui , ,e may be. for example, to print the digital work or to obtain a copv of the coital work 
The purpose will correspond ;o a specific usage right. In any event. Repository 1 checks the usaae nqhts associated 
wrth the digital work to determine if the access to the digital work may be grantee, step 105 The check o*' the usage 
rights essentially involves a determination of whether a right associated with the access request has been attached to 
the digital work and if all conditions associated with the right are satisfied. If the access is denied, repository 1 terminates 
the session with an error message, step 106. If access is granted, repository 1 transmits the digital wok to repository 
2. step 107. Once the digital work has been transmitted to repository 2. repository 1 and 2 each Generate billing infor- 
mation for the access which is transmitted to a credit server, step 105. Such double billing reporting is done to insure 
against attempts to circumvent the billing process. 

Figure 2 illustrates the basic interactions between repository types in the present invention. As will become apparent 
from Figure 2. the various repository types will serve different functions It is fundamental that repositories will share 
a core set of functionality which will enable secure and trusted communications. Referring to Figure 2 a repository 
201 represents the general instance of a repository The repository 201 has two modes of operation- a server mode 
and a requester mode. When in the server mode, the repository will be receiving and processing access requests to 
digital works. When in the requester mode, the repository will be initiating requests to access digital works Repository 
201 is general in the sense that its primary purpose is as an exchange medium for digital works. During the course of 
operation, Ihe repository 201 may communicate with a plurality of other repositories, namely authorisation repository 
202. rendering repository 203 and master repository 204 Communication between leposito.ies occuis utilizing a re- 
pository transaction protocol 205. 

Communication with an authorization repository 202 may occur when a digital work being accessed has a condition 
requiring an authorization. Conceptually an authorization is a digital certificate such that possession of the certificate 
is required to gam access to the digital work. An authorization is itself a digital work that can be moved between 
repositories and subjected to fees and usage rights conditions. An authorization may be required by both repositories 
involved in an access to a digital work. 

Communication with a rendering repository 203 occurs in connection with the rendering of a digital work As will 
be described in greater detail below, a rendering repository is coupled with a rendering device (eg'a printer device) 
30 to comprise a rendering system 

Communication with a master repository 205 occurs in connection with obtaining an identification certificate Iden- 
tification certificates are the means by which a repository is identified as "trustworthy". The use of identification certif- 
icates is described below with respect to the registration transaction. 

Figure 3 illustrates the repository 201 coupled to a credit server 301. The credit server 301 is a device which 
*> accumulates billing information for the repository 201. The credit server 301 communicates witn repository 201 via 
billing transactions 302 to record billing transactions. Billing transactions are reported to a billing clearinghouse 303 
by the credit server 301 on a periodic basis. The credit server 301 communicates to the billing clearinghouse 303 via 
clearinghouse transactions 304. The clearinghouse transactions 304 enable a secure and encrypted transmission of 
information to the billing clearinghouse 303. 
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RENDERING SYSTEMS 



A rendering system is generally defined as a system comprising a repository and a rendering device which can 
render a digital work into its desired form. Examples of a rendering system may be a computer system, a digital audio 
system, or a printer. A rendering system has the same security features as a repository. The coupling of a rendering 
repository with the rendering device may occur in a manner suitable lor the type of rendering device 

Figure 4a illustrates a printer as an example of a rendering system. Referring to Figure 4. printer system 401 has 
contained therein a printer repository 402 and a print device 403 It should be noted that the the dashed line defining 
printer system 401 defines a secure system boundary Communications within the boundai y are assumed to be secure 
Depending on the security level, the boundary also represents a barrier intended to provide physical integrity. The 
printer repository 402 is an instantiation of the rendering repository 205 of Figure 2. The printer repository 402 will in 
some instances contain an ephemeral copy of a digital work which remains until it is printed out by the print engine 
403. In other instances, the printer repository 402 may contain digital works such as fonts, which will remain and can 
be billed based on use This design assures that all communication lines between printers and printing devices are 
encrypted, unless they are within a physically secure boundary. This design feature eliminates a potential "fault" point 
through which the digital work could be improperly obtained. The printer device 403 represents the pr.nter components 
used to create the printed output. 

Also illustrated in Figure 4a is the repository 404. The repository 404 is coupled to the printer repository 402 The 
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repository 404 represents an external repository which contains digital works. 

Figure 4b is an example of a computer system as a rendering system A computer system may constitute a "multi- 
function" device since it may execute digital works le g software programs) and display digital works te a a digitized 
photograph). Logically, each rendering device can be viewed as having its own repository, although only one physical 
repository is needed. Referring to Figure 4b. a computer system 410 has contained therein a display/execution repos- 
itory 41 1 . The display/execution repository 41 1 is coupled to display device. 412 and execution device 41 3. The dashed 
box surrounding the computer system 410 represents a security boundary within which communications are assumed 
to be secure. The display/execution repository 411 is further coupled to a credit server 414 to report any fees to be 
billed for access to a digital work and a repository 41 5 for accessing digital works stored therein 

STRUCTURE OF DIGITAL WORKS 



Usage rights are attached directly to digital works. Thus, it is important to understand the structure of a digital work. 
The structure of a digital work, in particular composite digital works, may be naturally organized into an acyclic structure 
such as a hierarchy. For example, a magazine has various articles and photographs which may have been created 
and are owned by different persons. Each of the articles and photographs may represent a node in a hierarchical 
structure. Consequently, controls, i.e. usage rights, may be placed on each node by the creator. By enabling control 
and fee billing to be associated with each node, a creator of a work can be assured that the rignts and fees are not 
circumvented. 

In the currently preferred embodiment, the Nle information for a digiial work is divided into two files: a "contents" 
file and a "description tree" file. From the perspective of a repository, the "contents" file is a stieam of addiessable 
bytes whose format depends completely on the interpreter used to play display or print the digital work. The description 
tree file makes it possible to examine the rights and fees for a work without reference to the content of the digital work. 
It should be noted that the term description tree as used herein refers to any type of acyclic structure used to represent 
2B the relationship between the various components of a digital work 

Figure 5 illustrates the layout of a contents file. Referring to Figure 5. a digital work is comprised of story A 510, 
advertisement 511. story B 512 and story C 513. It is assumed that the digital work is stored starting at a relative 
address of 0. Each of the parts of the digital work are stored linearly so that story A 510 is stored at approximately 
addresses 0-30,000, advertisement 511 at addresses 30.001-40.000, story B 512 at addresses 40.001-60.000 and 
30 story C 513 at addresses 60.001 -85K. The detail of story A 51 0 is illustrated in Figure 6 Referring to Figure 6. the 
story A 510 is further broken down to show text 614 stored at address 0-1500. soldier photo 615 at addresses 
1501-10.000. graphics 516 stored at addresses 10.001 -25.000 and sidebar 617 stored address 25.001-30.000. Note 
that the data in the contents file may be compressed (for saving storage) or encrypted (for security). 

From Figures 5 and 6 it is readily observed that a digital work can be represented by its component parts as a 
hierarchy. The description tree for a digital work is comprised of a set of related descriptor blocks (d-blocks). The 
contents of each d-block is described with respect to Figure 7. Referring to Figure 7. a d-block 700 includes an identifier 
701 which is a unique identifier for the work in the repository, a starting address 702 providing the start address of the 
first byte of the work, a length 703 giving the number of bytes in the work, a rights portion 704 wherein the granted 
usage rights and their status data are maintained, a parent pointer 705 for pointing to a parent d-block and child pointers 
706 for pointing to the child d-blocks. In the currently preferred embodiment, the identifier 701 has two parts. The first 
part is a unique number assigned to the repository upon manufacture. The second part is a unique number assigned 
to the work upon creation. The rights portion 704 will contain a data structure such as a look-up table, wherein the 
various information associated with a right is maintained. The information required by the respective usage rights is 
described in more detail below D-blocks form a strict hierarchy. The top d-block of a work has no parent; all other d- 
blocks have one parent. The relationship of usage rights between parent and child d-blocks and how conflicts are 
resolved is described below. 

A special type of d-block is a "shell" d-block. A shell d-block adds no new content beyond the content of its parts. 
A shell d-block is used to add rights and fee information., typically by distributors of digital works. 

Figure 8 illustrates a description tree for the digital work of Figure 5. Referring to Figure 8. a top d-block 820 tor 
so the digital work points to the various stories and advertisements contained therein. Here, the top d-block 820 points to 
d-block 321 (representing story A 510), d-block 822 (representing the advertisement 511), d-block 823 (representing 
story B 512) and and d-block 824 (representing story C 513). 

The portion of the description tree for Story A 510 is illustrated in Figure 9. D-block 925 represents text 614, d- 
block 926 represents photo 615. d-block 927 represents graphics 516 by and d-block 928 represents sidebar 617. 

The rights portion 704 of a descriptor block is further illustrated in Figure 10. Figure 10 illustrates a structure which 
is repeated in the rights portion 704 for each right. Referring to Figure 10. each right will have a right code field 1050 
and status information field 1052 The right code field 1050 will contain a unique code assigned to a right. The status 
information field 1052 will contain information relating to the state of a right and the digital work Such information is 
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indicated below in Table 1. The righis as stored ,n tne rights portion 704 r 
the right code 



may typically be in numerical oraer oased on 
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I HOLE 1 

DIGITAL WORK STATE INFORMATION 




Property 


Value 


Use 


10 


oopies-in-use 


Number 


A counter of the number of copies of a work tnat are ,n use. Incremented when 
another copy is used: decremented when use is completed 




Lud n - r'e r loo 


Time-Units 


Indicator of the maximum number of time-units that a document can be loaned 




Loaner-Copy 


Boolean 


Indicator that the current work ,s a loaned out copy of an authorized digital work 


15 


Remaming-Time 


Time-Units 


Indicator of the remainina tim° of u«;p on a m^t^r^ ~ . - 

w >aii ly in 1 i_ ut>e on a metered document naht 




Documenl-Descr 


Siring 


A string conla.ning various identifying mlormaiion about a document The exact 
format of this .s not specified, but it can include information such as a publishe. 
name, author name, ISBN number, and so on. 


20 


Revenue-Owner 


RO-Descr 


A handle identifying a revenue owner for a digital work Th,s is used for reportina 
usage fees y 




Publication-Date 


Date-Descr 


The date that the digital work was published 


25 


History-list 


History-Rec 


A list of events recording the repertories and dates for operations that copy 
transfer backup, or restore a digital work 



30 



35 



40 



45 



50 



55 



ATTACHIN G USAGE RIGHTS TO A DIGITAL WORK 

work feVi^ ri 9 hts '-ted as par, of the digital work. As the digHa, 

a digital work is transferred from ^ %Zt7slZT* T^T 'Th °' narrowed - F °' e * am ^ whe " 
copy for a predetermined per^d of S^Si^^S^J^ T* ^ ^ " 9hl t0 '° an a 

work, the usage rights in the ^r^ ^S^^ ^l * repositor y ,oans oul a copy of the digital 

out the copy ^0^= 

server. In the case ofa digital wort S^o k? ? ' S processed ,or de P°^« in the digital work 

digital work is being crea 2 ^ AnTu.hor inq tSZ diSwo f ^ Van ° US COm *°™™ ,his ca " * done as the 
automated process^ attaching the usage 9 3 aSSemb " n9 ,0 °' C ° U ' d be U,i " 2ed which Prides for an 

a -x, se, o, rights- can be 

Resolving Conflicting Rights 



Because each pan of a digital work may have its own usage rights, there 



will be instances where the rights of a 
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"contained part" are different from its parent or container part. As a result conflict rules must be established to dictate 
when and how a right may be exercised The hierarchical structure of a digital work facilitates tne enforcement ot such 
rules. A "strict" rule would be as follows: a right for a part in a digital work is sanctioned if and only if it is sanctioned 
for the part, for ancestor d-blocks containing the part anc for all descendent d-blccks. By sanctioned it is mean; that 
5 (1) each of the respective parts must have the right, and (2) any conditions for exercising tne right are satisfied 

It also possible to implement the present invention using a more lenient rule In the more lenient rule access to 
the part may be enabled to the descendent parts wnich have the right, but access is denied to the descenoen;s which 
do not. 

An example of applying both the strict rule and lenient is illustrated with reference to Figure 11. Referring to Figure 
10 n : a root d-block 1101 has child d-blocks 1102-1105. In this case, root d-biock represents a magazine, and each of 
the child d-blocks 1102-1105 represent articles in the magazine. Suppose that a request is made to PRINT the cigital 
work represented by root d-block 1101 wherein the strict rule is followed. The rights for the root d-block 1101 and child 
d-blocks 1102-1 105 are then examined. Root d-block 1101 and child d-blocks 1102 and 1105 have been granted PRINT 
rights. Child d-block 1103 has not been granted PRINT rights and child d-block 1104 has PRINT rights conditioned on 
75 payment of a usage fee. 

Unaer the strict rule the PRINT right cannot be exercised because the child d-block does not have the PRINT right. 
Under the lenient rule, the result would be different. The digital works represented by child c-blocks 1102 and 1105 
could be printed and the digital work represented by d-block 1104 could be printed so long as the usage tee is oaid. 
Only the digital work represented by d-block 1103 could not be printed This same result would oe accomplished under 
20 the strict rule if the requests were directed lo each of Ihe individual digital works. 

The piesent invention supports various combinations of allowing and disallowing access. Moteovei. as will be 
described below, the usage rights grammar permits the owner of a digital work to specify if constraints may be imposed 
on the work by a container part. The manner in which digital works may be sanctioned because of usage rights conflicts 
would be implementation specific and would depend on the nature of the digital works. 

25 

REPOSITORIES 

In the description of Figure 2. it was indicated that repositories come in various forms All repositories provide a 
core set of services for the transmission of digital works The manner in which digital works are exchanged is the basis 
30 for all transaction between repositories The various repository types differ in the ultimate functions that they perform. 
Repositories may be devices themselves, or they may be incorporated into other systems An example is the rendering 
repository 203 of Figure 2. 

A repository will have associated with it a repository identifier Typically, the repository identifier would be a unique 
number assigned to the repository at the time of manufacture Each repository will also be classified as being in a 
35 particular security ciass. Certain communications and transactions may be conditioned on a repository being in a 
particular security class. The various security classes are described in greater detail below. 

As a prerequisite to operation, a repository will require possession of an identification certificate Identification 
certificates are encrypted to prevent forgery and are issued by a Master repository. A master repository plays the role 
of an authorization agent to enable repositories to receive digital works, identification certificates must be updated on 
-40 a periodic basis. Identification certificates are described in greater detail below with respect to the registration trans- 
action. 

A repository has both a hardware and functional embodiment. The functional embodiment is typically software 
executing on the hardware embodiment. Alternatively, the functional embodiment may be embedded in the hardware 
embodiment such as an Application Specific Integrated Circuit (ASIC) chip. 

-ts The hardware embodiment of a repository will be enclosed in a secure housing which if compromised, may cause 

the repository to be disabled. The basic components of the hardware embodiment of a repository are described with 
reference to Figure 1 2. Referring to Figure 1 2. a repository is comprised of a processing means 1 200. storage system 
1207, clock 1205 and external interface 1206. The processing means 1200 is comprised of a piocessoi element 1201 
and processor memory 1202. The processing means 1201 provides contioller, repository transaction and usage rights 

so transaction functions for the repository. Various functions in the operation of the repository such as decryption and/or 
decompression of digital works and transaction messages are also perlormed by the processing means 1200. The 
processor element 1201 may be a microprocessor or other suitable computing component. The processor memory 
1 202 would typically be further comprised of Read Only Memories (ROM) and Random Access Memories (RAM). Such 
memories would contain the software instructions utilized by the processor element 1201 in performing the functions 

55 of the repository. 

The storage system 1 207 is further comprised of descriptor storage 1 203 and content storage 1 204 The description 
tree storage 1203 will store the description tree for the digital work and the content storage will store the associated 
content The description tree storage 1 203 and content storage 1 204 need not be of the same type of storage medium. 
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nor are they necessarily on the same physical device. So for example the descriptor storage 1203 may be s.o.ed on 
a solid state storage (for rapid retrieval of the description tree .nformation). while the content storage 1204 may be on 
a high capacity storage such as an optical disk. 

The clock 1205 is used to time-stamp various time based conditions for usage rights or for melerma usage fee^ 
which may be associated with the digital works. The clock 1205 will have an uninterruptabie power supply" e g a 
battery, in order to ma.nta.n the integrity of the time-stamps. The external interface means 1206 provides for the signal 
connection to other repositories and to a credit server. The external interlace means 1205 provides for the exchange 
of signals via such standard interlaces such as R3-232 or Personal Computer Manufacturers Card Industry Assoc.at.on 
(PCMCIA) standards, or FDDI. The external interface means 1206 may also provide network connectivity 

The functional embodiment of a repository is described with reference to Figure 13 Referring to Figure 15 the 
functional embodiment .s comprised o! an operating system 1301. core repository services 1302. usage'transaction 
handlers 1303, repository specific functions, 1304 and a user interface 1305. The ooerating system 1301 is specific 
to the repository and would typically depend on the type of processor being used. The operating system 1 301 would 
also provide the basic services for controlling and interfacing between the basic components of the repository. 

The core repository services 1302 comprise a set of functions required by each and every repository. The core 
repository services 1302 mclude the sess.on initiation transactions which are det.ned in greater detail below This set 
of services also includes a gener.c t.cket agent which is used to -punch" a dig.tal ticket and a oenenc authorization 
server for process.ng authorization specifications. Digital tickets and authorizations are specific mechan.sms for con- 
trolling tne distribution and use of digital works and are described in more detail below. Note that coupled to the core 
repository services are a plurality of identification certificates 1306. The identilication cerlificates 1306 are required to 
enable the use of the repository. 

The usage transactions handlers 1303 comprise functionality for processing access requests to digital works and 
for billing fees based on access. The usage transactions supported will be different for each repository type For ex- 
ample, it may not be necessary for some repositories to handle access requests for digital works. 

The repository specific functionality 1304 comprises functionality that is unique to a repository. For example the 
master repository has special functionality for .ssuing digital cert.iicates and maintaining encryption keys The repository 
specific functionality 1 304 would include the user interface implementation lor the repository 

Repository Security Classes 

For some digital works the losses caused by any individual instance of unauthorized copying is insignificant and 
the chief economic concern lies in assuring the convenience of access and low-overhead billing In such cases simple 
and inexpensive handheld repositories and network-based workstations may be suitable repositories, even though the 
measures and guarantees of security are modest. 

At the other extreme, some digital works such as a digital copy of a first run movie or a bearer bond or stock 
certificate would be of very high value so that it is prudent to employ caution and fairly elaborate security measures to 
ensure that they are not copied or forged. A repository suitable for holding such a digital work could have elaborate 
measures for ensuring physical integrity and for verifying authorization before use. 

By arranging a universal protocol, all kinds of repositories can communicate with each other in principle However, 
creators of some works will want to specify that their works will only be transferred to repositories whose level of security 
is h.gh enough. For this reason, document repositories have a ranking system lor classes and levels of security. The 
security classes in the currently preferred embodiment are described in Table 2. 



TABLE 2 



45 




REPOSITORY SECURITY LEVELS 




Level 


Description of Security 


50 


0 


Open system. Document transmission is unencrypted. No digital certificate is required for identification 
The security of the system depends mostly on user honesty, since only modest knowledge may be needed 
to circumvent the security measures. The repository has no provisions for preventing unauthorized 
programs from running and accessing or copying files. The system does not pi event the use of removable 
storage and does not encrypt stored files. 


55 


1 


Minimal security. Like the previous class except that stored files are minimally encrypted including ones 
on removable storage. 



Continuation of the Table on the next page 
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TABLE 2 (continued'. 



Level 


Description ot Security 


2 


Basic security Like the previous class except that special tools and knowledge are reauired to 
compromise the programming, the contents of the repository, or the state of the clock All digiial 
communications are encrypted. A digital certificate is provided as loentmcation. Medium level encrypt.on 
is used. Repository identification number is unforgeabie 


3 


General security. Like the previous class plus the requirement of special tools arc needed to compromise 
the physical integrity of the repository and that modest encryption is used on all transmissions Password 
protection is required to use the local user inteface. Tne digital deck system cannot be reset without 
authorization. No works would be stored on removable storage When executing works as programs, it 
runs them in their own address space and does not give them direct access to any file storage or other 
memory containing system code or.works Tnen can access works only through the transmission 
transaction protocol 


4 


Like the previous class except that high level encryption is used on all communications Sensors are 
used to record attempts at physical and electronic tampering. Aftei such tampering, the lepositoiy will 
not perform other transactions until it has reported such tampering to a designated server. 


5 


Like the previous class except that if the physical or digital attempts at tampering exceed some preset 

thresholds that threaten the physical integrity of the repository or the integrity of digital and cryptographic 

barriers then the repository will save only document description records of history but will erase or destroy 

any digital identifiers that could be misused if released to an unscrupulous party. It also modifies any 

^i-vr+ifi/^oti-ie. -=»i ithnanti/-'itw ir\ i«Hirato that th<= nhvciirpH ^u^ipm has been compromised It also erases the 
cert in cat es or aumenuciiy io inuiocnt? inch uic^nyoiLai oyoicui nao u^cm ^wi i wi wm^^w ^ 

contents ot designated documents 


6 


Like the previousclass exceptthat the repository will attempt wireless communication to report tampering 
and will employ noisy alarms. 


10 


This would correspond to a very high level of security. This server would maintain constant 
communications to remote security systems reporting transactions, sensor readings and attempts to 
circumvent security. 



The characterization of security levels described in Table 2 is not intended to be fixed. More important is the idea 
of having different security levels for different repositories It is anticipated that new security classes and requirements 
will evolve according to social situations and changes in technology. 



Repository User interface 

A user interface is broadly defined as the mechanism by which a user interacts with a repository in order to invoke 
transactions to gain access to a digital work, or exercise usage rights. As described above, a repository may be em- 
bodied in various forms. The user interface for a repository will diffci depending on the particular embodiment. The 
user interface may be a graphical user interface having icons representing the digital works and the various transactions 
that may be performed. The user interface may be a generatec dialog in which a user is prompted for information. 

The user interface itself need not be part of the repository As a repository may be embedded in some other device, 
the user interface may merely be a part of the device in which the repository is embedded For example, the repository 
could be embedded in a "card" that is inserted into an available slot in a computer system The user interface may be 
a combination of a display, keyboard, cursor control device and software executing on the computer system. 

At a minimum, the user interface must permit a user to input information such as access requests and alpha 
numeric data and provide feedback as to transaction status. The user interface will then cause the repository to initiate 
the suitable transactions to service the request. Other facets of a particular user interface will depend on the functionality 
that a repository will provide. 

CREDIT SERVERS 

In the present invention, fees may be associated with the exercise ot a right. The requirement for payment of fees 
is described with each version of a usage right in the usage rights language The recording and reporting of such fees 
is performed by the credit server. One of the capabilities enabled by associating fees with rights is the possibility of 
supporting a wide range of charging models. The simplest model, used by conventional software, is that there is a 
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s.ng.e fee at the time ol purchase, after wh,cn the purchaser obtains unhm.ted r.gnts to use the work a, o.ten ard 

IS, 0f . Sf>e T' S A " ern?,,ive mode,s include metered use and variable fees A s.ng.e work can have d.flerent 
" *' ' er f n * US6S example viewin 9 a Photograph on a d.sp.ay could have different fees than rr,ak,no a hardcopy 

o 223 2 ' t 3 Cfea,ed W ° rk A 10 ,heSG a " emal,Ve Ch5r9in 9 mcaels 15 <° have a ^ overhead means 

of establishing fees and accounting for credit on these transactions 

k m i Cr ! dit ' iS 8 compu,ational s y s,em thal Pliably authorizes ans records these transactions so that fees a-e 
trani^nf 11k 6 ^ l ° * clear!nQh ° us e The billing clearinghouse manages the financial 

IZmT ,h V . ° CCUf 3 reSU " b '" S be 9enera ' ed and accoun,s ^onclec. Preferably the cred, server 
hLL ? k ,ransac,,ons and Periodically communicate via a network with the billing clearinghouse lor recon- 
secuntv llT.ZTT^ C ° mmu ™* l <°™ Wl,n ^ °««"9 clearinghouse would be encrypted Icr mteqnty and 
!mp- Z, , embodiment, the credit server acts as a "deb* card" where transactions occur'.n 'real- 

ume against a user account. 

oos.to^nltr 6 ' 15 COmprised ° f memor y a Processing means, a clock, and interlace means (or coupling to a re- 

tiese eS T"" ^ * ^ 88rver aiSO ,0 have Sec -* a " d authentication 

be horn fl? T eSSenlial, y ,he same elements as those of a repository Thus, a single device can 

2rSL n r , ' 3 Cr6d " S6rVer PrOV ' ded that " haS ,he aPPropr'a.e processing elements lor carry.no out the 
corresponding .unctions and protocols. Typically, however, a credit server would be a card-s.zed system ,n the pes 

HT?K°7 ha , Cr6dit CrSdiI iS C0UP ' ed ,0 3 repOSit ° ry and would ,n,eracI - "na c auran - 

» IT^ZT^Z ^ 3 finanCia ' ,nS, " Uti0n ° CCUr Pr ° ,OCOlS eS,aWlShed b * ..nanca, 

In the currently preferred embodiment credit servers associated with both the server and the leposi.o.y report the 
.nancia, transact™ to the billing clearinghouse. For example, when a digital work is copied by one repository to another 
s^tT k n" 5 COUP ' ed '° ° f rep0sitories -Pon the transaction to the billing clearinghouse TNs 
LZZTzlV T ,nSUreS j hat 3 tranSaCtion Wi " be acco — o ^r in the event of some break fn the communication 
crl^ Zl « 1 MHng clcarin 9 housc However, some implementations may embody only a Single 

credit server reporting the transaction to minimize transaction processing at the risk of losing some transactions. 

USAGE RIGHTS LANGUAGF 

The present invention uses statements in a h,gh level "usage rights language" to define rights associated with 
digital works and their parts. Usage rights statements are interpreted by repositor.es and are used to determine what 
transactions can be successfully earned out for a digital work and also to determine parameters (or those transacts 

b JZ7» h T T", '? lan9Ua9e de,erm ' ne Wh6,her 3 9 ' Ven d, 9' lal work ca " be ^Pied. when and how can 
'ees (.( any) are to be charged for that use. Once the usage r.ghts statements are generated, thej 
are encoded .n a suitable form for accessing during the processing of transactions 

.n^^T 9 USa9e ( n9h,S in ,erms of a iana ^ 9 e in combination with the hierarchical representation of a digital work 
enables the support of a w.de variety of d.s.r.bution and lee schemes. An example is the ability to attach multiple 
versions of a right to a work. So a creator may attach a PRINT right to make 5 cop.es for $10 00 and a^T^SE 
£tha, r,ohT' IT ' 0f * h°? °° C A PUfChaSer may ,hen Cho ° se Which OD,ion best needs. Another examp e 

woS Kle ? I? arS T t° ' n CaSS ° f 3 COmP ° £i,e W ° rk ,he r '9 htS and ,ees ol each o' the components 
works is used in determining the rights and fees for the work as a whole 

ccn^^^^^Tl^ illUS,ra,ed ^ F ' 9UrS M Re,emn9 '° R9Ure M ' 3 M9h ' 1450 has a transactional 
component 1451 and a specifications component 1452. A right 1450 has a label (e.g. COPY or PRINT) which indicates 

the use or d.s.nbut.on privileges that are embodied by the nght. The transact, component 1451 coTesponds^a 

bo^d n Wa f V 3 d,9 ' ,al WOfk may b6 US8d ° r dlS,nbU,ed The "ansactwna. component 1451 ,s typ.caMy Im 

bod^d ,n software instructions in a repository wh,ch implement the use or distribution privileges (or the rmh The 

orto S' r, COmP ° ne T S 1452 USSd '° SP9Ci,y C ° ndlli0nS WhlCh muS ' be sa,isfied pr,or «o ^ right being exercised 
or o des-gnate var.ous transacts related parameters. In the cuuen.ly preferred embodiment, these spec.f.ca.ions 
include copy count 1453, Fees and Incentives 1454, Time 1455, Access and Security ,456 and Control 1457 tach 
of these spec,f,ca„ons will be described in greater detail below with respect to the language grammar events 

The usage r.ghts language ,s based on the grammar described below. A grammar is a convenient means for 
defining valld sequ ence of symbols (or a (anguage. In describing the grammar the notation "(a. b IcJ" is used ToTZaZ 
distinct chcccs among alternatives. In this example, a sentence can have e.thcr an -a". "b» or "c" I, mustTocLae 

to descZth ^ 11 US6d t0 ind ' Ca,e ° P,i0nal ' temS N ° te ,hal brackeIS - ba - a "o bLes a re ed 

to describe the language of usage rights sentences but do not appear in actual sentences .n the language 

In contrast parentheses are part of the usage rights language. Parentheses are used to group Items tooether in 
hsts. The notation (x*) « used to indicate a var«b,e length lis,, that is. a lis. contain.ng one or I IZ^i yZ " 
The notation (x)* .s used to indicate a variable number of lists coniaining x 



2S 



30 



35 



40 



-IS 



BNSDOCID «EP_. 0715246A1 I > 



10 



EP 0 71 5 246 A1 



Keywords in the grammar are words followed by colons. Keywords are a common and very spec.al case in tnc 
language They are often used to indicate a single value typically an identifier In many cases the keyword and the 
parameter are entirely optional. When a keyword is given, it often takes a single identifier as its value. In some cases 
the keyword takes a list of identifiers. 
5 In the usage rights language, time is specified in an hours minutes:seconds '.or hh:mm:ss) representation Time 

zone indicators, e.g. PDT for Pacific Daylight Time, may also be specified. Dates are representee as year month/day 
(or YYYY/MMM/DD). Note that these time and date representations may specify moments in time or units of time 
Money units are specified in terms of dollars. 

Finally, in the usage rights language, various "things" will need to interact with each other. For example, an instance 
io of a usage right may specify a bank account a digital ticket, etc.. Such things need to be identified and are specified 
herein using the suffix "-ID." 

The Usage Rights Grammar is listed in its entirety in Figure 15 and is described beiow. 

Grammar element 1501 "Digital Work Rights: = (Rights*)" define the digital work rights as a set of rights. The 
set of rights attached to a digital work define how that digital work may be transferred, used, performed or played. A 

ts set of rights will attach to the entire digital work and in the case of compound digital works, each of the components of 
the digital work The usage rights of components of a digital may be different. 

Grammar element 1502 "Right : = (Right-Code {Copy-Count} {Control-Spec} {Time-Spec} {Access-Spec} 
{Fee-Spec}) M enumerates the content of a right. Each usage right must specify a right code. Each right may also 
optionally specify conditions which must be satisfied before the right can oe exercised. These conditions are copy 

20 count, control, lime, access and fee conditions. In the currently preferred embodimenl. lor the optional elements, the 
following defaults apply: copy count equais 1, no time limit on the use of the right, no access tests or a security level 
required to use the right and no fee is required. These conditions will each be described in greater detail below. 

It is important to note that a digital work may have multiple versions of a right, each having the same right code 
The multiple version would provide alternative conditions and fees for accessing the digital work. 

25 Grammar clement 1 503 "Right-Code : = Render-Code I Transport-Code I File-Management-Codel Derivative- 

Works- Code Configuration-Code" distinguishes each of the specific rights into a particular right type (although each 
right is identified by distinct right codes). In this way the grammar provides a catalog of possible rights that can be 
associated with parts of digital works. In the following, rights are divided into categories for convenience in describing 
them 

30 Grammar element 1504 'Render-Code : = [Play : {Player: Player-ID}IPrint: {Printer: Printer-ID}]" lists a cat- 

egory of rights all involving the making of ephemeral, transitory, or non-digital copies of the digital work After use the 
copies are erased. 

• Play A process of rendering or performing a digital work on some processor. This includes such things as playing 
35 digital movies, playing digital music, playing a video game, running a computer program, or displaying a 

document on a display. 

• Print To render the work in a medium that is not further protected by usage rights, such as printing on paper. 

Grammar element 1505 "Transport-Code :=[Copy I Transfer I Loan {Remaining-Rights: Next-Set-of-Rights}] 
J0 {(Next-Copy-Rights: Next-Set of Rights)}" lists a category of rights involving the making of persistent, usable copies 
of the digital work on other repositories. The optional Next-Copy-Rights determine the rights on the work after it is 
transported. If this is not specified, then the rights on the transported copy are the same as on the original. The optional 
Remaining-Rights specify the rights that remain with a digital work when it is loaned out. If this is not specified, then 
the default is that no rights can be exercised when it is loaned out 

• Copy Make a new copy of a work 

• Transfer Moving a work from one repository to another. 

• Loan Temporarily lodning a copy to another repository for a specified period ol time. 

so Grammar element 1506 "File-Management-Code : = Backup {Back-Up-Copy-Rights: Next-Set -of Rights}l 

Restore I Delete I Folder I Directory {Name: Hide-Local I Hide-Remote}{Parts:Hide-LocaHHide-Remote} M lists a 
category of rights involving operations for file management, such as the making of backup copies to protect the copy 
owner against catastrophic equipment failure. 

Many software licenses and also copyright law give a copy owner the right to make backup copies to protect against 

55 catastrophic failure of equipment. However, the making of uncontrolled backup copies is inherently at odds with the 
ability to control usage, since an uncontrolled backup copy can be kept and then restored even after the authorized 
copy was sold. 

The File management rights enable the making and restoring of backup copies in a way that respects usage rights. 
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honoring the requirements of both the copy owner and the rights grantor and revenue owner. Backup copies oi wo k 
descriptions (including usage rights and fee data) can be sent unoer appropriate orotocol and usaoe rights control lo 
otner document repositories of sufficiently high security. Further rights permit organization of aigitafworks into folder* 
which themselves are treated as digital works an- whose contents may be "mdden" from a party seeding to determine 
the contents of a repository. 

• Backup To make a backup copy of a digital work as protection against media failure 

• Restore To restore a backup copy of a digital work. 

• Delete To delete or erase a copy of a digital work. 

• Folder To create and name folders, and to move files and folders between folders. 

• Directory To hide a folder or its contents. 

Grammar element 1507 "Derivative- Works-Code : [ExtractlEmbedlEdit{Process: Process-ID}] {Next-Copy- 
Rights : Next-Set-of Rights}" lists a category of rights involving the use of a digital work to create new works 

• Extract To remove a portion of a work, for the purposes of creating a new work. 

• Embed To include a work in an existing work. 

• Edit To alter a digital work by copying, selecting and modifying portions of an existing digital work. 

Grammar element 1508 "Configuration-Code : = Install I Uninstall" lists a category of rights for inslalima and 
un.nstall.ng software on a repository (typically a rendering repository) This would typically occur for the installation of 
a new type of player within the rendering repository. 

• install: To install new software on a repository. 

• Uninstall: To remove existing software from a repository. 

Grammar element 1509 "Next-Set-of-Rights : = {(Add: Set-Of-Rights)} {(Delete: Set-Of-Rights)} {(Replace: 
Set-Of-Rights)} {(Keep: Set-Of-Rights)} M defines how rights are carried forward for a copy of a digital work. If the 
Next-Copy-Rights is not specified the rights for the next copy are the same as those of the current copy. Otherwise 
the set of rights for the next copy can be specified Versions of rights after Add are added to the current set of rights 
Rights after Delete: are deleted from the current set of rights If only right codes are listed after Delete then all versions 
of rights with those codes are deleted. Versions of rights after Replace: subsume all versions of rights of the same tVDe 
in the current set of rights. 

If Remainmg-Rights is not specified, then there are no rights for the oriqmal after all Loan copies are loaned out 
If Rema.mng-Rights is specified, then the Keep: token can be used to simplify the expression of what rights to keep 
behind. A list of right codes following keep means that all of the versions of those listed rights are kept in the remaining 
copy. This specification can be overridden by subsequent Delete: or Replace: specifications. 

Copy Count Specification 

For various transactions, it may be desirable to provide some limit as to the number of "copies" of the work which 
may be exercised simultaneously for the right. For example, it may be des.rable to limit the number of copies of a digital 
work that may be loaned out at a time or viewed at a time. 

Grammar element 1510 "Copy-Count : = (Copies: positive-integer I 0 I unlimited)" provides a condition which 
- defines the number of "copies" of a work subject to the right A copy count can be 0. a fixed number, or unlimited The 
copy-count is associated with each right, as opposed to there being just a single copy^ount for the digital work The 
Copy-Count for a right is decremented each time that a right is exercised When the Copy-Count equals zero the right 
can no longer be exercised. If the Copy-Count is not specified, the default is one. 

50 Control Specification 

Rights and fees depend in general on rights granted by the creator as well as further restrictions imposed by later 
distributors. Control specifications deal with interactions between the creators and their distributors governing the im- 
position of further restrictions and fees. For example, a distributor of a digital work may not want an end consumer of 
a digital work to add fees or otherwise profit by commercially exploiting the purchased digital work 

Grammar element 1511 "Control-Spec : = (Control: {Resectable I Unresectable} {Unchargeable I Charge- 
able})- provides a condition to specify the effect of usage rights and fees of parents on the exercise of the right A 
digital work is restrictable if higher level d-blocks can impose further restrictions (time specifications and access spec- 
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ifications) on the right. It is unresectable if no further restrictions can be imposed. The default setting is resirictabie 
A right is unchangeable if no more fees can be imposed on the use of the right It is charaeaole if more fees c*n he 
imposed The default is chargeable 

5 Time Specification 

It is often desirable to assign a start date or specify some duration as to when a right may be exercised Grammar 
element 1512 "Time-Spec : = ({Fixed-Interval I Sliding-lnterval I Meter-Time} Until: Expiration-Date)" provides 
for specification of time conditions on the exercise of a right. Rights may be granted for a specified time. Different kinds 

io of time specifications are appropriate tor different kinds of rights. Some rights may be exercised during a fixed and 
predetermined duration. Some rights may be exercised for an interval that starts tne first time that the right is invoked 
by some transaction. Some rights may be exercised or are charged according to some kind of metered time, which 
may be split into separate intervals. For example, a right to view a picture for an hour might be split into six ten minute 
viewings or four fifteen minute viewings or twenty three minute viewings 

is The terms "time" and "date" are used synonymously to refer to a moment in time. There are several kinds of time 

specifications. Each specification represents some limitation on the times over which the usage right applies. The 
Expiration-Date specifies the moment at which the usage right ends. For example, it the Expiration-Date is "Jan 1. 
1995," then the right ends at the first moment of 1995. If the Expiration-Date is specified as MoreverV then the rights 
are interpreted as continuing without end. If only an expiration date is given, then the right can be exercised as often 

20 as desired until the expiration dale. 

Grammar element 1513 "Fixed-Interval : = From: Start-Time" is used to define a predetermined inteival that 
runs from the start time to the expiration date. 

Grammar element 1514 "Sliding-lnterval: = Interval: Use-Duration" is used to define an indeterminate (or 
"open") start time. It sets limits on a continuous period of time over which the contents are accessible. The period starts 

25 on the first access and ends after the duration has passed or the expiration date is reached, whichever comes first. 
For example, if the right gives 10 hours of continuous access, the use-duration would begin when the first access was 
made and end 10 hours later. 

Grammar element 1515 "Meter-Time : = Time-Remaining: Remaining-Use" is used to define a "meter time," 
that is, a measure of the time that the right is actually exercised It differs from the Sliding-lnterval specification in that 

30 the time that the digital work is in use need not be continuous. For example, if the rights guarantee three days of access, 
those days could be spread out over a month. With this specification, the rights can be exercised until the meter time 
is exhausted or the expiration date is reached, whichever comes first 

Remaining-Use: = Time-Unit 
35 Start-Time: = Time-Unit 

Use-Duration: = Time-Unit 

All of the time specifications include time-unit specifications in their ultimate instantiation 

40 Security Class and Authorization Specification 

The present invention provides for various security mechanisms to be introduced into a distribution or use scheme. 
Grammar element 1516 "Access-Spec : = ({SC: Security-Class} {Authorization: Authorization-ID*} {Other-Au- 
thorization: Authorization-ID*} {Ticket: Ticket-ID})" provides a means tor restricting access and transmission. Ac- 
^5 cess specifications can specify a required security class for a repository to exercise a right or a required authorization 
test that must be satisfied. 

The keyword "SC:" is used to specify a minimum security level tor the repositories involved in the access. If "SC: 
" is not specified, the lowest security level is acceptable. 

The optional "Authorization:" keyword is used to specify requited authorizations on the same lepositoiy as the 
so work. The optional "Other-Authorization:" keyword is used to specify required authorizations on the other repository 
in the transaction. 

The optional "Ticket:" keyword specifies the identity of a ticket required for the transaction. A transaction involving 
digital tickets must locate an appropriate digital ticket agent who can "punch" or otherwise validate the ticket before 
the transaction can proceed. Tickets are described in greater detail below. 
55 in a transaction involving a repository and a document server, some usage rights may require that the repository 

have a particular authorization, that the server have some authorization, or that both repositories have (possibly dif- 
ferent) authorizations. Authorizations themselves are digital works (hereinafter referred to as an authorization object) 
that can be moved between repositories in the same manner as other digital works Their copying and transferring is 
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subject lo the same rights and fees as other digital works. A repository is said to have an autnonzauon ii that aunoi- 
ization object is contained within the repository 

In some cases, an authorization may be required from a source other than the document server and repository 
An authorization object referenced by an Autnorizaiion-ID can con;air. digital address iniormat.on to oe used id set up 
a communications link between a repository and the authorization source. These are analogous to phone numoers 
For such access tests, the communication would need to be established and authorization obta.ned before the right 
could be exercised. 

For one-time usage rights, a variant on this scheme is to have a digital ticket. A ticket is presented to a digital ticket 
agent, whose type is specified on the ticket. In the simplest case, a certified generic ticket agent, available on all 
repositories, is available to "punch" the ticket. In other cases, the ticket may contain addressing information lor locating 
a "special" ticket agent. Once a ticket has been punched, it cannot be used again for the same kind of transaction 
(unless it is unpunched or refreshed in the manner described below.) Punching includes marking the ticket with a 
timestamp of the date and time it was used. Tickets are digital works and can be copied or transferred between repos- 
itories according to their usage rights. 

In the currently preferred embodiment, a "punched" ticket becomes "unpunched" or "refreshed" when it is copied 
or extracted. The Copy and Extract operations save the date and time as a property of the digital ticket. When a ticket 
agent is given a ticket, it can simply check whether the digital copy was made after the last time that it was punched. 
Of course, the digital ticket must have the copy or extract usage rights attached thereto 
The capability to unpunch a ticket is inportant in the following cases 

A digital work is circulated at low cost with a limitation that it can be used only once. 

A digital work is circulated with a ticket that can be used once to give discounts on purchases of other works. 
A digital work is circulated with a ticket (included in the purchase price and possibly embedded in the work) that 
can be used for a future upgrade. 

In each of these cases ; if a paid copy is made of the digital work (including the ticket ) the new owner would expect 
to get a fresh (unpunched) ticket, whether the copy seller has used the work or not. In contrast, loaning a work or simply 
transferring it to another repository should not revitalize the ticket. 

30 Usage Fees and Incentives Specification 

The billing for use of a digital work is fundamental to a commercial distribution system. Grammar Element 1517 
"Fee-Spec: = {Scheduled-Discount} Regular-Fee-Spec I Scheduled-Fee-Spec I Markup-Spec" provides a range 
of options for billing for the use of digital works. 

A key feature of this approach is the development of low-overhead billing for transactions in potentially small 
amounts. Thus, it becomes feasible to collect fees of only a few cents each for thousands of transactions. 

The grammar differentiates between uses where the charge is per use from those where it is metered by the time 
unit. Transactions can support fees that the user pays for using a digital work as well as incentives paid by the right 
grantor to users to induce them to use or distribute the digital work 

The optional scheduled discount refers to the rest of the fee specification-discounting it by a percentage over 
time If it is not specified, then there is no scheduled discount. Regular fee specifications are constant over time. 
Scheduled fee specifications give a schedule of dates over which the fee specifications change. Markup specifications 
are used in d-blocks for adding a percentage to the fees already being' charged 

Grammar Element 1518 "Scheduled-Discount:= (Scheduled-Discount: (Time-Spec Percentage)*)" A Sched- 
uled-Discount is a essentially a scheduled modifier of any other tee specification tor this version of the right of the 
digital work. (It does not refer to children or parent digital works or to other versions of rights ). It is a list of pairs of 
times and percentages The most recent time in the list that has not yet passed at the time of the transaction is the 
one in effect. The percentage gives the discount percentage. For example, the number 10 refers to a 10% discounl. 

Grammar Element 1519 "Regular- Fee-Spec : = ({Fee: I Incentive: } [Per-Use-Spec I Metered- Rate-Spec I 
Best-Price-Spec I Ca I l-For- Price-Spec ] {Min: Money-Unit Per: Time-Spec}{Max: Money-Unit Per: Time-Spec} 
To: Account-ID)" provides for several kinds of fee specifications. 

Fees are paid by the copy-owner/user to the revenue-owner if Fee: is specified Incentives are paid by the revenue- 
owner to the user if Incentive: is specified. If the Min: specification is given, then there is a minimum fee to be charged 
per time-spec unit for its use. If the Max: specification is given, then there is a maximum fee to be charged per time- 
spec for its use. When Fee: is specified, Account-ID identifies the account to which the fee is to be paid. When In- 
centive: is specified, Account-ID identifies the account from which the fee is to be paid. 

Grammar element 1520 "Per-Use-Spec: = Per-Use: Money-unit" defines a simple fee to be paid every time the 
right is exercised, regardless of how much time the transaction takes 
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Grammar element 1521 M Metered-Rate-Spec : = Metered: Money-Unit Per: Time-Spec " defines a metered-ra.e 
fee paid according to how long the right is exercised Thus, the time it takes to comolete the transaction determines 
the fee. 

Grammar element 1522 M Best-Price-Spec : = Best-Price: Money-unit Max: Money-unit" is used to soecify a 
> best-price that is determined when the account is settled This specification is to accommodate special deals, rebates, 
and pricing that depends on information that is not available to the repository All fee specifications can be combined 
with tickets or authorizations that could indicate that the consumer is a wholesaler or that he is a preferred customer 
or that the seller be authorized in some way. The amount of money in the Max: field is tne maximum amount that the 
use will cost. This is the amount that is tentatively debited from the credit server. However, when the transaction is 
o ultimately reconciled, any excess amount will be returned to the consumer in a separate transaction 

Grammar element 1523 "Call-For-Price-Spec : = Call-For-Price M is similar to a "Best-Price-Spec" in that it is 
intended to accommodate cases where prices are dynamic. A Call-For-Price Spec requires a communication with a 
dealer to determine the price. This option cannot be exercised if the repository cannot communicate with a dealer at 
, the time that the right is exercised. It is based on a secure transaction whereby the dealer names a price to exercise 
75 the right and passes along a deal certificate which is referenced or included in the billing process. 

Grammar element 1524 "Scheduled-Fee-Spec: = (Schedule: (Time-Spec Regular-Fee-Spec)*)" is used to pro- 
vide a schedule of dates over which the fee specifications change. The tee specification with the most recent date not 
in the future is the one that is in effect. This is similar to but more general than the scheduled discount It is more 
general, because it provides a means to vary the fee agreement for each time period. 
20 Grammar element 1525 "Markup-Spec: s Markup: percentage To: Account-ID" is provided for adding a per- 

centage to the fees already being charged. For example, a 5% markup means that a fee of 5% of cumulative fee so 
far will be allocated to the distributor. A markup specification can be applied to all of the other kinds of fee specifications. 
It is typically used in a shell provided by a distributor. It refers to fees associated with d-blocks that are parts of the 
current d-block. This might be a convenient specification for use in taxes, or in distributor overhead. 

25 

REPOSITORY TRANSACTIONS 

When a user requests access to a digital work, the repository will initiate various transactions. The combination 
of transactions invoked will depend on the specifications assigned for a usage right There are three basic types of 

30 transactions, Session Initiation Transactions, Financial Transactions and Usage Transactions Generally, session ini- 
tiation transactions are initiated first to establish a valid session. When a valid session is established, transactions 
corresponding to the various usage rights are invoked. Finally, request specific transactions are performed. 

Transactions occur between two repositories (one acting as a server), between a repository and a document play- 
back platform (e.g. for executing or viewing), between a repository and a credit server or between a repository and an 

35 authorization server. When transactions occur between more than one repository, it is assumed that there is a reliable 
communication channel between the repositories. For example, this could be a TCP/IP channel or any other commer- 
cially available channel that has built-in capabilities for detecting and correcting transmission errors. However, it is not 
assumed that the communication channel is secure. Provisions for security and privacy are part of the requirements 
for specifying and implementing repositories and thus form the need for various transactions. 

40 

Message Transmission 

Transactions require that there be some communication between repositories. Communication between reposi- 
tories occurs tn units termed as messages. Because the communication line is assumed to be unsecure, all commu- 

45 nicanons with repositories that are above the lowest security class are encrypted utilizing a public key encryption 
technique. Public key encryption is a well known technique in the encryption arts. The term key refers to a numeric 
code that is used with encryption and decryption algorithms. Keys come in pairs : where "writing keys" are used to 
encrypt data and "checking keys" are used to decrypt data. Both writing and checking keys may be public or private. 
Public keys are those that are distributed to others. Private keys are maintained in confidence. 

so Key management and security is instrumental in the success of a public key encryption system. In the currently 

p re f erreC ! embodiment, one or more master repositories maintain the keys and create the identification certificates 
used by the repositories. 

When a sending repository transmits a message to a receiving repository the sending repository encrypts all of 
its data using the public writing key of the receiving repository. The sending repository includes its name, the name of 
55 the receiving repository, a session identifier such as a nonce (described below), and a message counter in each mes- 
sage. 

In this way the communication can only be read (to a high probability) by the receiving repository, which holds the 
private checking key for decryption The auxiliary data is used to guard against various replay attacks to security If 
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A usage transaction is carried out in a sess.on between repositories. For usage transactions mvolvmq more than 
f^ZT"* Z ° f ,inanC,a ' ,ranSac,IOns belween a Wito V and a credit server, a registration , a I per 
eLT^n f , f ransac,lon ,ermed a '°9*n transaction, may also be needed to initiate the session The goal of the 

St2SS2T2 0n ' S eStab,iSh 3 S6CUre Channe ' 6e ' Ween tW ° re P° srtor '« «*> know each others .dem.t.es As 
.1 is assumed that the commun.cat,on channel between the repositories is reliable but not secure ther- „ a risk that 
a non-repos.tory may mime the protocol in order to gain illegitimate access to a repository. 

hoc Th h e / l e 9 ls,ratlon transaction between two repositor.es is described with respect to Figures 15 and 17 The steps 
described are Irom the perspective ot a Vepository-1 ■ registering its identity with a 'repository*' The req strat.on must 
be symmetrica, so the same set o. steps will be repeated tor repos.tory* registering rep os °ZT 
Reternng to Figure 16. repos.tory-1 f.rst generates an encrypted registration identifier step 1601 and hen generates 
fdlnET T**, St6P 16 ° 2 ' A re9i£,ra,IOn mSSSa9e " COmpriSed of an identifie ' °< E master f ep 0 9 *™ a °l 

fentp ^ bvle'ma ^ " ""^ Mm M « The ^ntificatio'n certSicl 

.s encryp ed by the master repository ,n ,ts private key and attests to the (act thai the reoos.lory (here repos.to.v-1 ) is 

TeveTa'nd a E2nT ! h :' den, ' f,Ca,,0n C6rtif ' Cale a,SO a P""* key for the repository, the " P X" seel ^ 

level and a t.mestamp (indicating a time after which the certificate is no longer valid ) The registration identifier is a 
number generated by the repository for this registration. The registration identifier is unique to te sestZ and is 

toc^no cl'" TT °T rS PriVa ' e re9 ' S,ra,IOn ,den,ifler iS US6d to — 'V <- authen foa on by d 

Jtory* s^ep 1603 COmmUniCa, '° nS baSCd al,acks ^Po-tory-1 then transmits the registration message to rcpos- 

Upon receiving the registration message, repository-2 determines if it has the needed public key tor the master 

%^z^\ np ??^ does not have ,he needed pub,,c key ,o decrypt ,he iden " fica,i ° n o^:z 

registration transaction terminates in an error, step 1618 

itorv T S lZlVZVn PO T7' 2 Pr ° Per PUb " C lden,ifica,io " is decrypted, step 1605 Repos- 

itory-2 saves the encrypted registration identifier, step 1606. and extracts the repository identifier step 1607 The 
extracted repository identifier is checked against a "hotlist" of compromised document repositor e step 1608 I n^e 

S % e 'Z e tTTr each repository wi " con,a,n " ho,hsts " of — poised 

he hSs. when ihS T 3nSaC,ron termmaleS an err ° r P6r S,ep 1618 Repositories can be removed irZ 
iMoSi^ Z r l S 6XP,re S ° th3t ,he ' iSt d ° eS n °' need to 9 row wl,houI bou ^ Also, by keeping a sh^ 

s Th ° certificates that ,t has previously received, a repository can avoid the work of actually going Zugh the 

Ifo h k T 56 6nCryPted by 3 maSt9r rep ° si,or y A minor variatton °" the approach to improve efficiency 

tha h e vh e a H : eP0S,t0r 7 firS * 6XChan9e ' iS,S °' nam6S °' h0,llS, Cer,iflca,es -Itimate'y exchangi^tho^ s 

Note fha, n ll?r"T reC6,Ved " h0t " S,S " arS main,a ' ned and dlSUibu,ed b * Masler -posiLes 
Note that rather than terminating ,n error, the transaction could request that another registration message be sent 
based on an .den ,f.cat,on certificate created by another master repository Th.s may be repeated unTa savory 
identification certificate is found, or it is determined that trust cannot be established satisfactory 

reno^n^T 9 ^ re , p0si,ory is no1 on the ho,l ' s t repository identification needs to be verified In other words 
epos.tory-2 needs to validate that the repository on the other end ,s really repos,.ory-l Th.s .s termed Dedormance 

corZo, a n Per ' 0rmed " ° fder ,0 ,nVa " d aCC6SS ,0 ,hS "P-N » a couSerten reoo uoT ^repfay'g a re 
2 oeZ^Z SS>0n ' n ati ° n b6tWeen rePOSi, ° ry - 1 and re P° si '-V-2. Performance testing is initiated by ripos'^- 
2 generat.ng a performance message, step 1609. The performance message consists of a nonce the names o the 
respect.ve reposnor.es. the „me and the regis.ra.ion identifier received from reposi.ory-1 A nonclis o^Lled 

IT? 9 *, ° n S ° me rand ° m Va " able in,0fma,i0n < e * ,he - 'he temperature ) Z nonce fs usLd to 

check whether repos..ory-1 can actuaNy exhibit correct encrypting of a message us.ng the p r.va e keys it clafms o 

Tn the rTatrr 396 81 ,l ha ? neV6r be, ° re The P erto - an ^ message is encrypted using the pu^c key speTi ied 
, ,1 h/o 9 mSSSa9e ° f ^P 03 ' 10 ^- 1 The Performance message is transmitted to repos hory- 1 step 1610 ^ 

of the ,3 el ";° P0S,t0ry " 1 US ' n9 i,S PfiVa,C k ° y ^ S, ° P 1611 R °P°-ory-l then checks to make sure tha Unc names 
of the two repos.tor.es are correct, step 1612. that the time is accurate, step 161 3 and that the reqistraUon iden.T/r 
A 0 - 5 ' 0 "! 5 '° the one i, sen,, step 1614. „ any of these tests fails, the transaction 

Assuming that the testsare passed, repository-1 transmits the nonce to repository* in the clear Ten 161 TrI^o 
te^ 

terminates ,n an error per step 1618 If they are the same, the registration transaction has successfully c^ted 



40 



45 



50 



BNSDOCID <EP ..0715246A1 I > 



16 



EP 0 71 5 246 A1 



75 



At this point, assuming that the transaction has not terminated the repositories exchange messages containing 
session keys to be used in ail communications during the session and synchrony their ciocks Figure 17 illustrates 
the session information exchange and clock synchronization sieps (again from the perspective of repository-! Re- 
ferring to Figure 17. repository-1 creates a session key pair, steo 1701. A first key is kept private and is used by 
5 repository-1 to encrypt messages. The second key is a puolic key used by repository-2 to decrypt messages The 
second key is encrypted using the public key of repository-2. step 1702 and is sent to repository-2. step 1703 Upon 
receipt, repository-2 decrypts the second key. step 1704. The second key is used to decrypt messages in subsequent 
communications. When each repository has completed this step, they are both convinced that the ether repository is 
bona fide and that they are communicating with the original. Each repository has given the other a Key to be used in 
io decrypting further communications during the session. Since that key is itself transmitted :n tne public key of the re- 
ceiving repository only it will be able to decrypt the key which is used to decrypt subsequent messages 

After the session information is exchanged, the repositories must synchronize their clocks. Ciock synchronization 
is used by the repositories to establish an agreed upon time base for the financial records o\ their mutual transactions. 
Referring back to Figure 1 1, repository-2 initiates clock synchronization by generating a time stamp exchange message, 
step 1705. and transmits it to repository-1. step 1706. Upon receipt, repository-1 generates its own time stamp mes- 
sage, step 1707 and transmits it back to repository-2. step 1703. Repository-2 notes the current time, step 1709 and 
stores the time received t rom repository-1 . step 1710. The current time is compared to the time received from repository- 
1, step 1711. The difference is then checked to see if it exceeds a predetermined tolerance (e.g. one minute), step 
1712. If it does, repository-2 terminates the transaction as this may indicate tampering with the repository, step 1713. 
20 if not reposilory-2 computes an adjusted lime delta, step 1714. The adjusted lime delta is the difference between the 
clock time of repository-2 and the average of the times from repository-1 and repository-2. 

To achieve greater accuracy, repository-2 can request the time again up to a fixed number of times (e.g. five times), 
repeat the clock synchronization steps, and average the results. 

A second session initiation transaction is a Login transaction. The Login transaction is used to check the authenticity 
25 of a user requesting a transaction. A Login transaction is particularly prudent for the authorization of financial transac- 
tions that will be charged to a credit server. The Login transaction involves an interaction between the user at a user 
interface and the credit server associated with a repository. The information exchanged here is a login string supplied 
by the repository/credit server to identify itself to the user and a Personal Identification Number (PIN) provided by the 
user to identify himself to the credit server In the event that the user is accessing a credit server on a repository different 
30 from the one on which the user interface resides, exchange of the information would be encrypted using the public and 
private keys of the respective repositories. 

Billing Transactions 

35 Billing Transactions are concerned with monetary transactions with a credit server. Billing Transactions are carried 

out when all other conditions are satisfied and a usage fee is required for granting the request. For the most part, billing 
transactions are well understood in the state of the art These transactions are between a repository and a credit server 
or between a credit server and a billing clearinghouse. Briefly, the required transactions include the following: 

-*o • Registration and LOGIN transactions by which the repository and user establish their bona fides to a credit server 
These transactions would be entirely internal in cases where the repository and credit server are implemented as 
a single system. 

Registration and LOG IN transactions, by which a credit server establishes its bona fides to a billing clearinghouse. 
An Assign-fee transaction to assign a charge. The information in this transaction would include a transaction iden- 
tifier, the identities of the repositories in the transaction, and a list of charges from the parts of the digital work. If 
there has been any unusual event in the transaction such as an interruption of communications, that information 
is included as well. 

A Begin-charges transaction to assign a charge. This transaction is much the same as an assign-lee transaction 
except that it is used for metered use. It includes the same information as the assign-fee tiansaction as well as 
50 tne usage fee information. The credit-server is then responsible for running a clock. 

An End-charges transaction to end a charge for metered use. (In a variation on this approach, the repositories 
would exchange periodic charge information for each block of time.) 

A report-charges transaction between a personal credit server and a billing clearinghouse. This transaction is 
invoked at least once per billing period. It is used to pass along information about charges. On debit and credit 
55 cards, this transaction would also be used to update balance information and credit limits as needed. 

All billing transactions are given a transaction ID and are reported to the credit severs by both the server and the 
client This reduces possible loss of billing information if one of the parlies to a transaction loses a banking card and 
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provides a check against tampering with the system. 
Usage Transactions 
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rights specifications from the versions of the Loan right If there is only one version of tne Loan ngfi men tnc cetci- 
mination is simple The remaining rights are the ones specified in tnat version of the Loan ngh; O' none if Remamn^- 
Rights: is not specified. If there are multiple versions of the Loan right and all copies of all of the versions are loaned 
out. then the remaining rights is taken as the minimum set (intersection) of remaining rights across all of the versions 
5 of the loan right. The server then determines if the requested right is in the set of remaining rights step 1814 1 the 
requested right is not in the set of remaining rights, the server terminates the transaction step 1505 

If Loan is not a usage right for the digital work or if all cooies have not been loaned out or :he requested right is in 
the set of remaining rights, fee conditions for the right are then checked step 18"! 5. This will initiate various financial 
transactions between the repository and associated credit server. Further, any metering of usage of a digital work will 
10 commence. If any financial transaction fails, ihe transaction terminates per step 1505 

It should be noted that the order in which the conditions are checked need not follow the order of steps 1806-1515 

At this point, right specific steps are now performed and are represented here as step 1815. The right specific 
steps are described in greater detail below. 

The common closing transaction steps are now performed. Each of the closing transaction steps are performed 
'5 by the server after a successful completion of a transaction Referring back tc Figure 18. the copies in use value for 
the requested right is decremented by the number of copies involved in the transaction, step 1817. Next, if the right 
had a metered usage tee specification, the server subtracts the elapsed time trom the Remaimng-Use-Tirne associated 
with the right for every part involved in the transaction, step 1816. Finally, if there are fee specifications associated 
with the right, the server initiates End-Charge financial transaction to confirm billing, step 181 9. 

20 

Transmission Protocol 

An important area to consider is the transmission of the digital work from the server to the requester. The trans- 
mission protocol described herein refers to events occurring after a valid session has been created. The transmission 

2S> protocol must handle the case of disruption in the communications between the repositories. It is assumed that inter- 
ference such as injecting noise on the communication channel can be detected by the integrity checks (e g , parity, 
checksum, etc.) that are built into the transport protocol and are not discussed in detail herein. 

The underlying goal in the transmission protocol is to preclude certain failure modes, such as malicious or accidental 
interference on the communications channel Suppose for example, that a user pulls a card with the credit server at 

30 a specific time near the end of a transaction There should not be a vulnerable time at which "pulling the card" causes 
the repositories to fail to correctly account for the number of copies of the work that have been created. Restated, there 
should be no time at which a party can break a connection as a means to avoid payment after using a digital work. 

If a transaction is interrupted (and fails), both repositories restore the digital works and accounts to their state prior 
to the failure, modulo records of the failure itself. 

35 Figure 19 is a state diagram showing steps in the process of transmitting information during a transaction. Each 

box represents a state of a repository in either the server mode (above the central dotted line 1 901 ) or in the requester 
mode (below the dotted line 1 901 ). Solid arrows stand for transitions between states. Dashed arrows stand for message 
communications between the repositories. A dashed message arrow pointing to a solid transition arrow is interpreted 
as meaning that the transition takes place when the message is received. Unlabeled transition arrows take place 

-*o unconditionally. Other labels on state transition arrows describe conditions that trigger the transition. 

Referring now to Figure 19, the server is initially in a stale 1902 where a new transaction is initiated via start 
message 1903. This message includes transaction information including a transaction identifier and a count of the 
blocks of data to be transferred. The requester, initially in a wait state 1904 then enters a data wait state 1905. 

The server enters a data transmit state 1906 and transmits a block of data 1907 and then enters a wait for ac- 

-*5 knowledgement state 1908. As the data is received, the requester enters a data receive state 1909 and when the data 
blocks are completely received it enters an acknowledgement state 1910 and transmits an Acknowledgement message 
191 1 to the server. 

If there are more blocks to send, the server waits until receivingan Acknowledgement message horn the requester 
When an Acknowledgement message is received it sends the next block to the i equestei and again waits for acknowl- 
50 edgement. The requester also repeats the same cycle of states 

If the server detects a communications failure before sending the last block, it enters a cancellation state 191 2 
wherein the transaction is cancelled. Similarly if the requester detects a communications failure before receiving the 
last block it enters a cancellation state 1913. 

If there are no more blocks to send, the server commits to the transaction and waits for the final Acknowledgement 
55 in state 1914. If there is a communications failure before the server receives the final Acknowledgement message, it 
still commits to the transaction but includes a report about the event to its credit server in state 1915. This report serves 
two purposes It will help legitimize any claims by a user of having been billed for receiving digital works that were not 
completely received Also it helps to identify repositories and communications lines that have suspicious patterns of 
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use and interruption The server then enters its completion state 19 16. 

On the requester side, when there are nc more blocks to receive the requester commits to the transaction in slate 

1917. If the requester detects a communications failure at this state, it reports the failure to its credit server in state 

1918. but still commits to the transaction. When ii has committee, it sends an acknowledgement message to the server 
5 The server then enters its completion state 1 91 9. 

The key property is that both the server and the requester cancel a transaction if it is interrupted before all of the 
data blocks are delivered, and commits to it if all of the data blocks have been delivered 

There is a possibility that the server will have sent all of the data blocks (and committed) but the reouester will not 
have received all of them and will cancel the transaction. In this case both repositories will presumably detect a com- 
to munications failure and report it to tneir credit server. This case will probably be rare since it depends on very precise 
timing of the communications failure. The only consequence will be that the user at the requester repository may want 
to request a refund from the credit services -- and the case for that refund will be documented by repons by both 
repositories. 

To prevent loss of data, the server should not delete any transferred digital work until receiving the final acknowl- 
edgement from the requester. But it also should not use the file. A well known way to deal witn this situation is called 
"two-phase commit" or 2PC. 

Two-phase commit works as follows. The first phase works the same as the method described above The server 
sends all of the data to the requester. Both repositories mark the transaction (and appropriate files) as uncommitted. 
The server sends a ready-to-commit message to the requester. The requester sends back an acknowledgement. The 
server then commits and sends the requester a commit message. When the requester receives the commit message, 
it commits the file. 

If there is a communication failure or other crash, the requester must check back with the server to determine the 
status of the transaction. The server has the last word on this. The requester may have received all of the data, but if 
it did not get the final message, it has not committed The server can go ahead and delete files (except for transaction 
records) once it commits, since the files arc known to have been fully transmitted before starting the 2PC cycle. 

There are variations known in the art which can be used to achieve the same effect. For example, the server could 
use an additional level of encryption when transmitting a work to a client Only after the client sends a message ac- 
knowledging receipt does it send the key. The client then agrees to pay for the digital work. The point of this variation 
is that it provides a clear audit trail that the client received the work For trusted systems, however this variation adds 
30 a level of encryption for no real gain in accountability 

The transaction for specific usage rights are now discussed 

The Copy Transaction 

35 A Copy transaction is a request to make one or more independent copies of the work with the same or lesser 

usage rights. Copy differs from the extraction right discussed later in that it refers to entire digital works or entire folders 
containing digital works. A copy operation cannot be used to remove a portion of a digital work. 

• The requester sends the server a message to initiate the Copy Transaction. This message indicates the work to 
io be copied the version of the copy right to be used for the transaction, the destination address information (location 

in a folder) for placing the work the file data for the work (including its size), and the number of copies requested. 

• The repositories perform the common opening transaction steps. 
The server transmits the requested contents and data to the client according to the transmission protocol. If a 
Next-Set-Ot-Rights has been provided in the version of the right, those rights are transmitted as the rights tor the 
work. Otherwise, the rights of the original are transmitted. In any event, the Copy-Count field lor the copy of the 
digital work being sent right is set to the number-of-copies requested. 

The requester records the work contents data, and usage rights and stores the work. It records the date and time 
that the copy was made in the properties of the digital work. 
The repositories perform the common closing transaction steps. 
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The Transfer Transaction 

A Transfer transaction is a request to move copies of the work with the same or lesser usage rights to another 
repository. In contrast with a copy transaction, this results in removing the work copies from the server. 

• The requester sends the server a message to initiate the Transfer Transaction. This message indicates the work 
to be transferred, the version of the transfer right to be used in the transaction, the destination address information 
for placing the work, the file data for the work, and the number of copies involved 
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• The repositories perform the common opening transaction steps. 

The server transmits the requested contents and data to the requester according to the transmission protocol II 
a Next-Set-OI-Rights has been provided, those rights are transmitted as the rights for the work Otherwise the 
rights of the original are transmitted. 
5 In either case, the Copy-Count field for the transmitted rights are set to the number-o<-copies requestec 

• The requester records the work contents, data, and usage rights and stores the work 

• The server decrements its copy count by the number of copies involvec in the transaction. 

• The repositories perform the common closing transaction steps. 

• If the number of copies remaining in the server is now zero, it erases the digital work from its memory 

w 

The Loan Transaction 

A loan transaction is a mechanism for loaning copies of a digital work. The maximum duration of the loan is de- 
termined by an internal parameter of the digital work Works are automatically returned after a predetermined time 
15 period. 

The requester sends the server a message to initiate the Transfer Transaction. This message indicates tne work 
to be loaned the version of the loan right to be used in the transaction, the destination address information for 
placing the work, the number of copies involved, the file data for the work, and the period of the loan 
20 • The server checks the validity of the requested loan period, and ends with an error il the period is not valid. Loans 
for a loaned copy cannot extend beyond the period of the original loan to the server 

• The repositories perform the common opening transaction steps. 

• The server transmits the requested contents and data to the requester. If a Next-Set-Of-Rights has been provided, 
those rights are transmitted as the rights for the work. Otherwise, the rights of the original are transmitted, as 

25 modified to reflect the loan period. 

The requester records the digital work contents, data, usage rights, and loan period and stores the work. 
The server updates the usage rights information in the digital work to reflect the number of copies loaned out. 

• The repositories perform the common closing transaction steps. 

• The server updates the usage rights data for the digital work This may preclude use of the work until it is returned 
30 from the loan The user on the requester platform can now use the transferred copies of the digital work A user 

accessing the original repository cannot use the digital work . unless there are copies remaining. What happens 
next depends on the order of events in time. 

Case 1 . If the time of the loan period is not yet exhausted and the requester sends the repository a Return message. 

35 

• The return message includes the requester identification, and the transaction ID. 

The server decrements the copies-in-use field by the number of copies that were returned. (If the number of digital 
works returned is greater than the number actually borrowed, this is treated as an error.) This step may now make 
the work available at the server for other users. 
40 • The requester deactivates its copies and removes the contents from its memory. 

Case 2 If the time of the loan period is exhausted and the requester has not yet sent a Return message 

The server decrements the copies-in-use field by the number digital works that were borrowed. 
J5 • The requester automatically deactivates its copies of the digital work It terminates all current uses and erases the 
digital work copies from memory. One question is why a requester would ever return a work earlier than the period 
of the loan, since it would be returned automatically anyway. One reason for early return is that there may be a 
metered fee which determines the cost of the loan. Returning eaily may (educe that lee. 

so The Play Transaction 

A play transaction is a request to use the contents of a work. Typically, to "play" a work is to send the digital work 
through some kind of transducer, such as a speaker or a display device. The request implies the intention that the 
contents will not be communicated digitally to any other system. For example, they will not be sent to a printer, recorded 
55 on any digital medium, retained after the transaction or sent to another repository. 

This term "play" is natural for examples like playing music, playing a movie, or playing a video game. The general 
form of play means that a "player" is used to use the digital work. However, the term play covers all media and kinds 
of recordings Thus one wouid "play" a digital work, meaning, to render it for reading, or play a computer program, 
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meaning to execute it. For a digital ticket the player would be a digital ticket acen;. 

The requester sends the server a message to initiate the play transaction This message indicates the work to be 
played, the version of the play ngn: to be used in tne -ransaction. the identity of the player being used and the tile 
data for the work. 

• The server checks the validity of the player identification and the compatibility of the player identification win the 
player specification in the right. It ends with an error if these are not satisfactory 

• The repositories perform the common opening transaction steps. 

• The server and requester read and write the blocks of data as requested by the piayer according to the transmission 
protocol, i he requester plays the work contents, using the player 

When the player is finished, the player and the requester remove the contents from their memory. 

• The repositories perform the common closing transaction steps. 

The Print Transaction 

A Print transaction is a request to obtain the contents of a work for the purpose ot rendering them on a "printer." 
We use the term "printer" to include the common case of writing with ink on paper. However, the key aspect ot "printing" 
in our use of the term is that it makes a copy of the digital work in a place outside of the protection of usage rights. As 
with all rights, this may require particular authorization certificates. 

Once a digital work is printed, the publisher and user are bound by whatever copyright laws are in eflecl. However, 
printing moves the contents outside the control of repositories For example, absent any other enfoi cement mecha- 
nisms, once a digital work is printed on paper, it can be copied on ordinary photocopying machines without intervention 
by a repository to collect usage fees. If the printer to a digital disk is permitted, then that digital copy is outside of the 
control of usage rights. Both the creator and the user know this, although the creator does not necessarily give tacit 
consent to such copying, which may violate copyright laws. 

• The requester sends the server a message to initiate a Print transaction. This message indicates the work to be 
played, the identity of the printer being used, the file data for tne work, and the number of copies in the request. 

• The server checks the validity of the printer identification and the compatibility of the printer identification with the 
printer specification in the right It ends with an error if these are not satisfactory 

• The repositories perform the common opening transaction steps. 

• The server transmits blocks of data according to the transmission protocol. 

• The requester prints the work contents, using the printer 

• When the printer is finishes, the printer and the requester remove the contents from their memory. 
35 • The repositories perform the common closing transaction steps. 

The Backup Transaction 
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A Backup transaction is a request to make a backup copy of a digital work, as a protection against media failure. 
In the context of repositories, secure backup copies differ from otner copies in three ways: (1) they are made under 
the control of a Backup transaction rather than a Copy transaction. (2) they do not count as regular copies, and (3) 
they are not usable as regular copies. Generally, backup copies are encrypted. 

Although backup copies may be transferred or copied, depending on their assigned rights, the only way to make 
them useful tor playing, printing or embedding is to restore tnem. 

The output ot a Backup operation is both an encrypted data file that contains the contents and description of a 
work, and a restoration file with an encryption key for restoring the encrypted contents. In many cases, the encrypted 
data file would have rights for "printing" it to a disk outside of the protection system, relying just on its encryption for 
security. Such files could be stored anywhere that was physically safe and convenient The restoration file would be 
held in the repository. This file is necessary for the restoration of a backup copy. It may have rights for tiansfer between 
50 repositories. 

The requester sends the server a message to initiate a backup transaction. This message indicates the work to 
be backed up, the version of the backup right to be used in the transaction, the destination address information 
for placing the backup copy, the file data for the work. 
The repositories perform the common opening transaction steps. 

The server transmits the requested contents and data to the requester. It a Next-Set-Of-Rights has been provided, 
those rights are transmitted as the rights for the work Otherwise, a set of default rights for backup files of the 
original are transmitted by the server. 
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The requester records the work contents, data, and usage rights. It then creates a one-time key and encrypts the 
contents file. It saves the key information in a restoration file 
The repositories perform the common closing transaction steps. 



5 in some cases, it is convenient to be able to archive the large, encrypted contents file to secure offline storage 

such as a magneto-optical storage system or magnetic tape. This creation of a non-repository arcnive hie is as secure 
as the encryption process. Such non -repository archive storage is considered a form of "printing" and is controlled by 
a print right with a specified "archive-printer." An archive-printer device is programmed to save the encrypted contents 
file (but not the description file) offline in such a way that it can be retrieved 

10 

The Restore Transaction 



A Restore transaction is a request to convert an encrypted backup copy of a digital work into a usable copy A 
restore operation is intended to be used to compensate for catastrophic media failure. Like all usage rights, restoration 
75 rights can include fees and access tests including authorization checks. , 

• The requester sends the server a message to initiate a Restore transaction. This message indicates the work to 
be restored, the version of the restore right for the transaction, the destination address information for placing the 
work, and the file data for the work. 

20 • The server verifies that the contents file is available (i.e. a digital work corresponding to the request has been 
backed-up.) If it is not, it ends the transaction with an error. 

• The repositories perform the common opening transaction steps. 

• The server retrieves the key from the restoration file. It decrypts the work contents, data, and usage rights 

• The server transmits the requested contents and data to the requester according to the transmission protocol. If 
2$ a Ncxt-Sct-Of-Rights has been provided, those rights arc transmitted as the rights for the work. Otherwise, a set 

of default rights for backup files of the original are transmitted by the server. 

• The requester stores the digital work. 

• The repositories perform the common closing transaction steps. 



30 The Delete Transaction 

A Delete transaction deletes a digital work or a number of copies of a digital work from a repository. Practically all 
digital works would have delete rights. 



• The requester sends the server a message to initiate a delete transaction. This message indicates the work to be 
deleted, the version of the delete right for the transaction. 

• The repositories perform the common opening transaction steps. 

• The server deletes the file, erasing it from the file system. 

• The repositories perform the common closing transaction steps. 

The Directory Transaction 

A Directory transaction is a request for information about folders, digital works, and their parts. This amounts to 
roughly the same idea as protection codes in a conventional tile system like TENEX, except that it is generalized to 
the full power of the access specifications of the usage rights language. 

The Directory transaction has the important role of passing along descriptions of the rights and fees associated 
with a digital work When a user wants to exercise a right, the user interface of his repository implicitly makes a directory 
request to determine the versions of the right that are available. Typically these are presented to the usei - such as 
with different choices of billing for exercising a right. Thus, many diiectoiy transactions are invisible to the user and 
are exercised as part of the normal process of exercising ail rights. 

• The requester sends the server a message to initiate a Directory transaction. This message indicates the file or 
folder that is the root of the directory request and the version of the directory right used for the transaction. 

• The server verifies that the information is accessible to the requester. In particular, it does not return the names 
of any files that have a HIDE-NAME status in their directory specifications, and it does not return the parts of any 
folders or files that have HIDE-PARTS in their specification. If the information is not accessible, the server ends 
the transaction with an error. 

• The repositories perform the common opening transaction steps 
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• The server sends the requested data to the requester according to the transmission protocol 

• The requester records the data 

• The repositories perform the common closing transaction steps. 
The Folder Transaction 

A Folder transaction is a request to create or rename a folder, or to move a work between folders Togetner with 
Directory rights, Folder rights control the degree to whicn organization of a repository can be accessed or moditied 
from another repository 



The requester sends the server a message to initiate a Folder transaction. This message indicates the folder that 
is the root of the folder request, the version of the folder right for the transaction, an operation, and data The 
operation can be one of create, rename, and move file. The data are the specifications required for the operation, 
such as a specification of a folder or digital work and a name. 
*5 • The repositories perform the common opening transaction steps. 

The server performs the requested operation - creating a folder, renaming a folder, or moving a work between 
folders. 

• The repositories perform the common closing transaction steps. 
20 The Extract Transaction 

A extract transaction is a request to copy a part of a digital work and to create a new work containing it. The 
extraction operation differs from copying in that it can be used to separate a part of a digital work from d-blocks or 
shells that place additional restrictions or fees on it. The extraction operation differs from the edit operation in that it 
docs not change the contents of a work, only its embedding in d-blocks. Extraction creates a now digital work. 



• The requester sends the server a message to initiate an Extract transaction. This message indicates the part of 
the work to be extracted, the version of the extract right to be used in the transaction, the destination address 
information for placing the part as a new work : the file data for the work, and the number of copies involved 

30 • The repositories perform the common opening transaction steps 

The server transmits the requested contents and data to the requester according to the transmission protocol. If 
a Next-Set-Of-Rights has been provided, those rights are transmitted as the rights for the new work. Otherwise, 
the rights of the original are transmitted. The Copy-Count field for this right is set to the number-of-copies requested. 

• The requester records the contents, data, and usage rights and stores the work. It records the date and time that 
35 new work was made in the properties of the work. 

• The repositories perform the common closing transaction steps. 

The Embed Transaction 



An embed transaction is a request to make a digital work become a part of another digital work or to add a shell 
d-block to enable the adding of fees by a distributor ot the work. 

• The requester sends the server a message to initiate an Embed transaction. This message indicates the work to 
be embedded, the version of the embed right to be used in the transaction, the destination address information 
for placing the part as a a work the file data for the work, and the number ot copies involved 

• The server checks the control specifications for all of the rights in the part and the destination. If they are incom- 
patible, the server ends the transaction with an error. 

• The repositories perform the common opening transaction steps. 
The server transmits the requested contents and data to the requester according to the transmission protocol. If 
a Next-Set-Of-Rights has been provided, those rights are transmitted as the rights for the new work. Otherwise, 
the rights of the original are transmitted. The Copy-Count field for this right is set to the number-of-copies requested. 
The requester records the contents, data, and usage rights and embeds the work in the destination file. 

• The repositories perform the common closing transaction steps. 

55 The Edit Transaction 

An Edit transaction is a request to make a new digital work by copying selecting and modifying portions of an 
existing digital work This operation can actually change the contents of a digital work The kinds of changes that are 
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permitted depend on the process being used Like the extraction operation edit operates on poriions of a cignai work 
In contrast with the extract operation, edit does not aflect tne rights or location of the work It only changes the contents 
The kinds of changes permitted are determined by the type specification of the processor specified in the rights In the 
currently preferred embodiment, an edit transaction changes the work itself and does not make a new work However 
5 it would be a reasonable variation to cause a new copy of the work to be made 

• The requester sends the server a message to initiate an Edit transaction. This message indicates the work to be 
edited, the version of the edit right to be used in the transaction, the file data for the work (including its stze> the 
process-ID for the process, and the number of copies involved 

• The server checks the compatibility of the process-ID tc be used by the requester agams: any process-ID speci- 
fication in the right. If they are incompatible it ends the transaction with an error. 

• The repositories perform the common opening transaction steps. 

• The requester uses the process to change the contents of the digital work as desired. (For example, it can select 
and duplicate parts of it: combine it with other information: or compute functions based on the information This 
can amount to editing text, music, or pictures or taking whatever other steps are useful in creating a derivative work. ) 

• The repositories perform the common closing transaction steps. 

The edit transaction is used to cover a wide range of kinds of works. The category describes a process that takes 
as its input any portion of a digital work and then modifies the input in some way. For example, for text, a process for 
editing the text would require edit rights. A process for "summarizing" or counting words in the text would also be 
considered editing. For a music file, processing could involve changing the pitch or tempo, or adding i eve i be i a lions, 
or any other audio effect. For digital video works, anything which alters the image would require edit rights Examples 
would be colorizing, scaling, extracting still photos, selecting and combining frames into story boards, sharpening with 
signal processing, and so on. 

Some creators may want to protect the authenticity of their works by limiting the kinds of processes that can be 
performed on them. If there are no edit rights, then no processing is allowed at all A processor identifier can be included 
to specify what kind of process is allowed If no process identifier is specified, then arbitrary processors can be used. 
For an example of a specific process, a photographer may want to allow use of his photograph but may not want it to 
be colorized A musician may want to allow extraction of portions of his work but not changing of the tonality 

Authorization Transactions 

There are many ways that authorization transactions can be defined. In the following, our preferred way is to simply 
define them in terms of other transactions that we already need for repositories. Thus, it is convenient sometimes to 
speak of "authorization transactions." but they are actually made up of other transactions that repositories already have. - 
A usage right can specify an authorization-ID. which identifies an authorization object (a digital work in a file of a 
standard format) that the repository must have and which it must process. The authorization is given to the generic 
authorization (or ticket) server of the repository which begins to interpret the authorization. 

As described earlier, the authorization contains a server identifier which may just be the generic authorization 
server or it may be another server. When a remote authorization server is required, it must contain a digital address. 
It may also contain a digital certificate. 

If a remote authorization server is required, then the authorization process first performs the following steps: 

• The generic authorization server attempts to set up the communications channel. (If the channel cannot be set 
-ts up, then authorization fails with an error) 

• When the channel is set up, it performs a registration process with the remote repository, (if registration fails, then 
the authorization fails with an error.) 

• When registration is complete, the generic authorization server invokes a "Play'' transaction with the remote re- 
pository, supplying the authorization document as the digital woi k to be played, and the remote authorization server 

so (a program) as the "player." (If the player cannot be found or has some other error then the authorization fails with 

an error) 

• The authorization server then "plays" the authorization. This involves decrypting it using either the public key of 
the master repository that issued the certificate or the session key from the repository that transmitted it. The 
authorization server then performs various tests. These tests vary according to the authorization server They 

55 include such steps as checking issue and validity dates of the authorization and checking any hot-lists of known 

invalid authorizations. The authorization server may require carrying out any other transactions on the repository 
as well, such as checking directories, getting some person to supply a password, or playing some other digital 
work It may also invoke some special process for checking information about locations or recent events The 
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"script" for such steps is contained within the authorization server 
• If all of the required steps are completed satisfactorily, the authorization server completes the transaction normally 
signaling that authorization is granted. 

The Install Transaction 

An Install transaction is a request to install a digital work as runnable software on a repository In a typical case, 
the requester repository is a rendering repository and the software would be a new kind or new version of a player. 
Also in a typical case, tne software would be copied to file system of the requester repository before it is installed. 



• The requester sends the server an Install message. This message indicates the work to be installed, the version 
of the Install right being invoked, and the file data for the work (including its size). 

• The repositories perform the common opening transaction steps. 

• The requester extracts a copy of the digital certificate for the software. If the certificate cannot be found or the 
'5 master repository for the certificate is not known to the requester the transaction ends with an error. 

• The requester decrypts the digital certificate using the public key of the master repository, recording the identity 
of the supplier and creator, a key for decrypting the software, the compatibility information, and a tamper^checkmg 
code. (This step certifies the software.) 

The requester decrypts the software using the key from the certificate and computes a check code on it using a 
1-way hash lunclion. If the check-code does not match the tamper-checking code from the certificate the instal- 
lation transaction ends with an error. (This step assures that the contents of the software, including the various 
scripts, have not been tampered with.) 

The requester retrieves the instructions in the compatibility-checking script and follows them. If the software is not 
compatible with the repository, the installation transaction ends with an error (This step checks platform compat- 
25 ibility.) 

The requester retrieves the instructions in the installation script and follows them. If there is an error in this process 
(such as insufficient resources), then the transaction ends with an error. Note that the installation process puts the 
runnable software in a place in the repository where it is no longer accessible as a work for exercising any usage 
rights other than the execution of the software as part of repository operations in carrying out other transactions 
30 • The repositories perform the common closing transaction steps 

The Uninstall Transaction 

An Uninstall transaction is a request to remove software from a repository. Since uncontrolled or incorrect removal 
35 of software from a repository could compromise its behavioral integrity, this step is controlled. 

The requester sends the server an Uninstall message. This message indicates the work to be uninstalled, the 
version of the Uninstall right being invoked, and the file data for the work (including its size) 
The repositories perform the common opening transaction steps 

The requester extracts a copy of the digital certificate tor the software. If the certificate cannot be found or the 
master repository for the certificate is not known to the requester, the transaction ends with an error. 
The requester checks whether the software is installed If the software is not installed the transaction ends with 
an error. 

The requester decrypts the digital certificate using the public key of the master repository, recording the identity 
of the supplier and creator, a key for decrypting the software, the compatibility information, and a tamper-checking 
code. (This step authenticates the certification of the software, including the script for uninstalling it.) 

• The requester decrypts the software using the key from the certificate and computes a check code on it using a 
1-way hash function. If the check-code does not match the tamper-checking code fiom the certificate the instal- 
lation transaction ends with an error. (This step assures that the contents of the softwaie. including the various 

50 scripts, have not been tampered with.) 

• The requester retrieves the instructions in the uninstallation script and follows them. If there is an error in this 
process (such as insufficient resources), then the transaction ends with an error. 

• The repositories perform the common closing transaction steps. 
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Claims 

1. A method for controlling access to and distribution of a composite digital work, said composite digital work com- 
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prising a plurality of parts said method comprising the steps of: 

a) creating a composite digital work. 

b) creating a description structure for said composite digital work, said description structure ccmpris ng a 
5 plurality of description blocks, each of said description blocks storing access information for at least one of 

said plurality of parts of said composite digital work: 

c) storing said description structure and said composite digital work in a repository: 

d) said repository receiving a request to access said composite digital work, sad request having one or more 
request attributes: and 

w e) said repository determining if said request may be granted by examining the access information for each 

description block of said description structure of said composite digital work witn respect to said one or more 
request attributes of said request. 

The method as recited in Claim 1 wherein said step of creating a composite digital work is further comprised of 
the steps of: 

at) creating a first part of said digital work 

a2) creating a first description block for said first part of said composite digital work: 

a3) obtaining an existing second pan for said composite digital work, said second part of the digital work having 
a second description block. 

a4) combining said first part and said second part to form said composite digital woik. and 
a5) creating a third description block for said composite digital work. 

The method as recited in Claim 2 wherein said step of creating a description structure for said composite digital 
work is further comprised of the step of linking said first description block, said second description block and said 
third description block to correspond to the organization of said composite digital work. 

The method as recited in Claim 3 wherein said step of storing said description structure and said composite digital 
work in a repository is further comprised of the steps of storing said description structure in a first storage means 
and said composite digital work in a second storage means. 

The method as recited in Claim 4 wherein each of said first description block, said second description block and 
said third description block is comprised of a pointer to a corresponding part of said composite digital work stored 
in said second storage means and a control information part for storing usage rights for said corresponding part 
of said digital work and said step of creating a first description block for said first part of said composite digital work 
is further comprised of the step of specifying a first set of usage rights and storing in said control information part 
of said first description block. 

The method as recited in Claim 1 wherein said step of creating a description structure for said composite digital 
work is further comprised of the step of adding a shell description block for specifying usage rights and fees of a 
distributor of said composite digital work 

The method as recited in Claim 2 wherein said step of obtaining an existing second part for said composite digital 
work is further comprised of the step of extracting said second part from an existing digital work. 

A repository for storing and controlling access to composite digital works comprising: 

an interface means for receiving requests to access digital works sloied therein, 
a first storage unit for storing digital data representing digital works. 
so a second storage unit for storing description structures for digital works stored in said first storage unit, said 

description structure comprising a plurality of description blocks, each of said description blocks comprising: 
a pointer to a parent description block one or more pointers to children description blocks, a pointer to a 
corresponding part of a digital work stored in said first storage unit and a usage rights part for storing one or 
more usage rights, each of said usage rights specifying an instance of how said part may be used; 
55 a transactions processor for processing requests to access a digital work, said transactions processor com- 

prising a means for identifying a usage right from a request to access said digital work, and a means for 
determining if a description block contains an identified usage right 
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9. The repository as recited in claim 8 wherein said transaction processor is further comprised of usaae riahis ccniUci 
resolution means for resolving usage rights conflicts between different description blocks 

10. A system for controlling access to and usage of composite digital works, said composite diaital work comons.no 
a plurality of digital works, said system comprising: 

means for attaching usage rights to digital works, said usage rights indicating how a recipient o: a digital work 
may use and subsequently distribute said digital work: 

means for creating a description structure for said composite aigital work, saio description structure comprising 
a description block for each digital work of said composite digital work, said description biocK comprising said 
usage rights for said digital work and addressing information for said digital work: 

a plurality of repositories for managing exchange of digital works based on usage rights attacned to said aigital 
works, each of said plurality of document repositories comprising a storage means for storing digital works a 
processor having a first server mode of operation for processing access requests to said digital works and a 
second requester mode of operation for initiating requests to access digital works, a timekeeping means and 
a connection means: 

a rendering system for rendering of digital works, said rendering system comprising a rendering reoository for 
secure receipt of composite digital works and a rendering device having means for converting digital signals 
to signals suitable for rendering of said digital works. 
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1501 — Digital Work Rights: = (Rights*) 

1 502 — Right : = (Right-Code {Copy-Count} {Control -Spec} {Time-Spec } 
{Access-Spec} {Fee-Spec}) 

7503— Right-Code : = Render-Code | Transport-Code | File-Management- 
Code| Derivative-Works- Code | Configuration -Code 
1504 — Render-Code : = [ Play : {Player: Player-ID} | Print: {Printer: Printer-ID}] 
7505-— Transport-Code : = [Copy | Transfer | Loan {Remaining-Rights: 

Next-Set-of-Rights}]{(Next-Copy-Rights: Next-Set-of-Rights)} 
1506— File-Managemcnt-Code := Backup {Back-Up-Copy-Rights: 

Next-Set-of-Rights} | Restore | Delete | Folder 
i Directory {Name: Hide-Local | Hide-Remote} 
{Parts: Hide-Local | Hide-Remote} 

7507 Derivative- Works-Code : = [Extract | Embed | Edit{P rocess: 

Process-ID}] {Next-Copy-Rights : 
Next-Set-of Rights} 

1508— Configuration-Code := Install | Uninstall 

1509 — Next-Set-of-Rights := {(Add: Set-Of-Rights)} {(Delete: 
Set-Of-Rights)} {(Replace: Set-Of-Rights )M(Keep: Set-Of-Rights )} 

1510— Copy-Count := (C op ies:positive- integer | 0 1 Unlimited) 
151 1 '—Control-Spec : = (Control: {Restrictable | Unresectable} 

{Unchargeable | Chargeable}) 
7572— Time-Spec : = ({Fixed-Interval | Sliding-Interval | Meter-Time} 

Until: Expiration-Date) 
1513— Fixed-Interval := From: Start-Time 
1514* — Sliding-Interval : — Interval: Use-Duration 
15 75--— Meter- Time: = Time-Remaining: Remaining-Use 
1516— Access-Spec : = ({SC: Security-Class} {Authorization: Authorization-ID*} 

{Other-Authorization: Authorization-ID*} {Ticket: Ticket-ID}) 
7577— -Fee-Spec: = {Scheduled-Discount} Regular-Fee^Spec | Scheduled -Fee-Spec | 
Markup-Spec 

1518— Scheduled-Discount: = Scheduled-Discount: (Scheduled-Discount: 

(Time-Spec Percentage)*) 

1519 — Regular- Fee-Spec := ({Fee: | Incentive: } fPer-Use-Spec | Metered-Rate- 

Spec | Best-Price-Spec | Call-For-Price-Spec] 
{Min: Money-Unit Per: Time-SpecHMax: 
Money-Unit Per: Time-Spec} To: Account- ID) 
1520 — Per-Use-Spec: = Per-Use: Money-unit 

1521 ~-Metered-Rate-Spec : = Metered: Money -Unit Per: Time-Spec 
1522~— Best-Price-Spec := Best-Price: Money-unit Max: Money-unit 
7523— -Call-For-Price-Spec := Call-For -Price 

1524— Scheduled-Fee-Spec:= (Schedule: (Time-Spec Regular-Fee-Spec)* ) 

7525— -Markup-Spec: = Markup: percentage To: Account-ID 

Fig.15 
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